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]

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.

The way I actually wanted is to have a Save Image node at the end and no other node that can save images. (Many Nodes that have a Output image can save images but are not the Save Image Node)

The special node way would mean you have workflows that work only for the canvas. (or have a not needed node in the workflow tab.)

There are 2 others ways:
Form Builder annotation approach — In the canvas workflow integration modal, let the user tag which image-producing output nodes should return results to canvas, similar to how they already select the input ImageField via radio buttons. The execution code would only apply CANVAS_OUTPUT_PREFIX to those tagged nodes.

For the staging area to support multiple returns, getOutputImageName would need to become getOutputImageNames (return all canvas output images), and each would appear as a separate staging area item.

[dunkeroni]

The special node way would mean you have workflows that work only for the canvas. (or have a not needed node in the workflow tab.)

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".

If in the future we expand the feature to also take bbox inputs (composite raster area, inpaint mask, regional collection), then that will also require a specialty node as well. I think it's a good idea to build around explicit workflow definitions intended for canvas in that case.