Fix: Renderer fails to recover from type error after undo

[jsjgdh]

Regression of #3783 .

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request refactors the error handling within the node graph executor to improve robustness and consistency. Instead of immediately exiting the evaluation process upon encountering an error, the system now captures and defers error propagation. This ensures that all available messages are processed and that error-related responses are dispatched only at the conclusion of the evaluation cycle, leading to more stable state management.

Highlights

• Refactored Error Handling: The poll_node_graph_evaluation function was updated to defer error reporting, allowing it to process all incoming NodeGraphUpdate messages before potentially returning an error.
• Deferred Error Responses: New mechanisms were introduced to store error-related messages, such as NodeGraphMessage::UpdateTypes and NodeGraphMessage::SendGraph, and dispatch them only if an error occurred during processing.
• Consistent State Clearing: The logic for clearing click_targets, vector_modify, and last_svg_canvas was centralized and applied consistently when an error state is detected, whether it's an execution or compilation error.

Changelog

• editor/src/node_graph_executor.rs
  • Refactored error handling in poll_node_graph_evaluation to defer error returns.
  • Introduced error and deferred_error_responses variables to manage error state and messages.
  • Modified error branches to store error information and continue processing instead of early exiting.
  • Ensured click_targets, vector_modify, and last_svg_canvas are cleared upon error.
  • Updated the function's return logic to propagate the stored error at the end of the evaluation loop.

Activity

• No specific activity has been recorded for this pull request yet.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request refactors error handling in poll_node_graph_evaluation to process all available responses from the node graph runtime, rather than returning on the first error. This is a positive change for robustness. However, I've identified a critical bug in the new implementation where a successful response can incorrectly clear an error state from a preceding failed response, potentially masking failures. I've provided suggestions to fix this. Additionally, I've included a suggestion to simplify the final error handling logic for better clarity.

[Keavon]

/gemini review

[gemini-code-assist]

Code Review

The pull request refactors the error handling within the poll_node_graph_evaluation function, introducing a graph_render_error flag for better state management and recovery. It centralizes error propagation by deferring the return of an Err until the end of the function, allowing for processing of all responses in a batch. My feedback focuses on improving the consistency and completeness of error reporting, as well as removing redundant message dispatches. These improvements aim to make error diagnostics more comprehensive and the code cleaner.

[jsjgdh]

/gemini review

[gemini-code-assist]

Code Review

This pull request refactors the error handling in the node graph executor to make it more resilient, preventing it from halting on the first error. It also includes a fix for providing default values for node inputs. The changes are generally good, but I've identified a couple of areas for improvement in terms of code readability and maintainability.

[cubic-dev-ai]

No issues found across 2 files

[cubic-dev-ai]

1 issue found across 1 file

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="editor/src/node_graph_executor.rs">

<violation number="1" location="editor/src/node_graph_executor.rs:58">
P2: `last_svg_canvas` is never set to `Some(...)` anywhere in the codebase, making the field dead code and every `self.last_svg_canvas = None` assignment a no-op. If this field is intended to retain a `SurfaceFrame` reference to keep a canvas surface alive (e.g., between renders), the code that populates it appears to be missing.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[cubic-dev-ai]

P2: last_svg_canvas is never set to Some(...) anywhere in the codebase, making the field dead code and every self.last_svg_canvas = None assignment a no-op. If this field is intended to retain a SurfaceFrame reference to keep a canvas surface alive (e.g., between renders), the code that populates it appears to be missing.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At editor/src/node_graph_executor.rs, line 58:

<comment>`last_svg_canvas` is never set to `Some(...)` anywhere in the codebase, making the field dead code and every `self.last_svg_canvas = None` assignment a no-op. If this field is intended to retain a `SurfaceFrame` reference to keep a canvas surface alive (e.g., between renders), the code that populates it appears to be missing.</comment>

<file context>
@@ -55,6 +55,8 @@ pub struct NodeGraphExecutor {
 	futures: VecDeque<(u64, ExecutionContext)>,
 	node_graph_hash: u64,
 	previous_node_to_inspect: Option<NodeId>,
+	last_svg_canvas: Option<SurfaceFrame>,
+	graph_render_error: bool,
 }
</file context>