Feature(UI): Canvas Workflow Integration - Run Workflow on Raster Layer

[Pfannkuchensack]

Summary

This PR adds a Canvas Workflow Integration feature that allows users to execute workflows directly on canvas layers, with a dedicated canvas_output backend node and an entry-based staging area that supports multiple output images.

Canvas Workflow Integration

Adds a new modal dialog accessible from raster layer context menus that enables users to:

• Select workflows that have Form Builder enabled, at least one image input field, and a Canvas Output node
• Automatically pass the current canvas layer as the image input
• Adjust workflow parameters through an interactive form interface (supports all field types: string, int, float, bool, enum, scheduler, board, model, image)
• Execute the workflow and have results appear in the canvas staging area

Canvas Output Node

Adds a new CanvasOutputInvocation backend node (canvas_output) that explicitly marks which images should be routed to the canvas staging area. This replaces a fragile heuristic that detected output nodes by scanning for board input fields.

Breaking change: Workflows need a Canvas Output node to work with canvas workflow integration.

Entry-Based Staging Area

Rearchitects the staging area so each canvas_output node in a workflow produces its own navigable entry. A workflow with 2 Canvas Output nodes will show 2 separate thumbnails in the staging area strip, each individually selectable and acceptable.

Bug Fixes

• Fixes "Input should be a valid dictionary or instance of BoardField" error when queuing workflows containing nodes with board fields. The frontend stores board values as 'auto'/'none' strings which the backend rejects — these are now filtered during graph construction.
• Fixes async race condition in staging area where optimistic status updates could overwrite complete data, using a generation counter pattern.
• Handles workflow execution errors and invocation failures with proper state cleanup and user-facing error toasts.

QA Instructions

1. Setup: Create a workflow with Form Builder enabled, an image input field, and at least one Canvas Output node
2. Single output: Run workflow from canvas → verify result appears in staging area and can be accepted onto canvas
3. Multiple outputs: Create workflow with 2 Canvas Output nodes → verify 2 separate entries appear in staging area strip, each with its own thumbnail, individually navigable with arrow keys
4. Parameter adjustment: Verify all field types render correctly in the modal form and values are applied during execution
5. Board field fix: Create workflow that includes a save_image node alongside canvas_output → verify it queues without "BoardField" validation error
6. Workflow filtering: Verify workflows without a canvas_output node do NOT appear in the canvas workflow selector
7. Error handling: Test with an invalid workflow configuration → verify error toast appears and modal returns to usable state
8. Navigation: With multiple entries, verify next/prev cycling wraps correctly across item boundaries
9. Accept: Select a specific entry from a multi-output item → verify only that single image is accepted onto the canvas

Video Demo

Demo

Merge Plan

No special merge considerations. Standard merge to main is fine.

Checklist

• The PR has a short but descriptive title, suitable for a changelog
• Tests added / updated (if applicable)
• ❗Changes to a redux slice have a corresponding migration
• Documentation added / updated (if applicable)
• Updated What's New copy (if doing a release after this PR)

[joshistoast]

This feature looks like an awesome addition to Invoke! Just from watching the video my only feedback would be to do away with that image checkbox and upload section, I think we can safely assume they're running that workflow on the image layer and don't need that extra semi-confusing step. Unless I'm missing something ofc.

[Pfannkuchensack]

Some workflows can have more then one Image input so you need that selection Option. Maybe not if there is only one but this can be done later.

[dunkeroni]

Some issues I ran into with my testing:

1. (minor) If the workflow errors, then the canvas stays in the result selection mode with an "in progress" item that never goes away until the user cancels. Not sure if we can capture and escape that easily, but it would be nice to do.
2. (QOL) If a workflow only has one not-yet-filled image field, then it should be automatically selected. I expect that sort of input structure will be the primary use case.
3. If the form builder has other image fields (requiring upload, or already containing an image by default) then they are not visually contained to the upload box in the modal.

4. If the workflow has multiple image intermediates, then it seems like only the first one is returned as the result to canvas. Should we use a special node that exits only to identify an image as a return for the canvas operations? That could allow the user to control one or multiple results as well.

[Pfannkuchensack]

I don't necessarily see that as a bad thing. If I have lots of workflows saved, it is helpful for the canvas interactions to only show the compatible subset that I have made to work as raster layer filters. It could also allow sending back multiple results or intermediates per workflow without that functionality being tied to (or intercepting) the save to gallery. If I do have a workflow that already takes an image and outputs another, then adding one node after my normal save image makes it "canvas-capable".

there is now a output canvas node.

[dunkeroni]

Interactions between canvas and workflows are going to need further PRs, but this is a sold framework that we can build on for that.