Skip to content

Fixed stop graph deactivation cascade.#34

Merged
lextatic merged 2 commits into
mainfrom
feature/stop-graph-deactivation-cascade
Jun 8, 2026
Merged

Fixed stop graph deactivation cascade.#34
lextatic merged 2 commits into
mainfrom
feature/stop-graph-deactivation-cascade

Conversation

@lextatic

@lextatic lextatic commented Jun 8, 2026

Copy link
Copy Markdown
Contributor

Fixed

  • Fixed input properties not being able to resolve during graph deactivation.

@lextatic lextatic added the fixed General bug fixes label Jun 8, 2026
@lextatic lextatic requested a review from Copilot June 8, 2026 01:06

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR adjusts graph shutdown ordering so property-backed inputs can still be resolved while the StopGraph deactivation cascade is running (before the processor reference is cleared).

Changes:

  • Delay clearing GraphContext.Processor until after EntryNode.StopGraph(...) to keep property resolution working during deactivation.
  • Add a lifecycle test that asserts a property-backed input can be resolved via an OnDeactivate path during StopGraph().

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File Description
Forge/Statescript/GraphProcessor.cs Reorders shutdown steps in StopGraph() to keep the processor available during the disable cascade.
Forge.Tests/Statescript/GraphProcessorTests.cs Adds a regression test ensuring property-backed inputs resolve during StopGraph() deactivation.
Comments suppressed due to low confidence (1)

Forge/Statescript/GraphProcessor.cs:121

  • StopGraph is no longer re-entrancy safe: during the disable cascade, nodes like ExitNode can call graphContext.Processor?.StopGraph() while Processor is still set, causing a nested StopGraph that clears Processor/contexts mid-cascade and may invoke OnGraphCompleted multiple times. Add a guard (e.g., HasStarted) so any re-entrant StopGraph during the cascade becomes a no-op, while still keeping Processor set for property resolution.
	public void StopGraph()
	{
		if (GraphContext.Processor != this)
		{
			return;
		}

		// Clear HasStarted first so the disable cascade is re-entrancy safe (e.g. an ExitNode triggering StopGraph, or a
		// state node reaching FinalizeGraph) without nulling Processor yet. Keeping Processor set throughout the cascade
		// lets action nodes on OnDeactivate paths still resolve property-backed inputs.
		GraphContext.HasStarted = false;
		Graph.EntryNode.StopGraph(GraphContext);
		GraphContext.Processor = null;
		GraphContext.ActiveStateNodes.Clear();
		GraphContext.InternalNodeActivationStatus.Clear();
		GraphContext.RemoveAllNodeContext();
		OnGraphCompleted?.Invoke();
	}

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@lextatic lextatic merged commit d10cf0d into main Jun 8, 2026
1 check passed
@lextatic lextatic deleted the feature/stop-graph-deactivation-cascade branch June 8, 2026 01:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

fixed General bug fixes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants