feat: preview method endpoint

[ltdrdata]

• post method /preview_method is added

#6205

[huchenlei]

I don't think there should be an extra endpoint to configure server state, as this makes the server stateful and not suitable for parallel request processing. I would suggest we add the preview method as an optional param to POST /prompt endpoint, and set the latent_preview there.

The benefit is to make the API less stateful.

[ltdrdata]

I don't think there should be an extra endpoint to configure server state, as this makes the server stateful and not suitable for parallel request processing. I would suggest we add the preview method as an optional param to POST /prompt endpoint, and set the latent_preview there.

The benefit is to make the API less stateful.

I have reviewed the proposed change once again.

Using that approach makes the preview_method dependent on the prompt item.
In other words, depending on the state of the preview_method at the time the queue is triggered, the preview may appear or disappear while the prompt is being executed.
(This also means that changes to preview_method are not reflected immediately.)

If preview_method is not tied to the prompt item and is instead changed globally without directly sending the /prompt API (separately from queueing it), the logic for preview_method state changes will be handled within the /prompt, which feels unnatural.

I think we need to discuss whether this is the right approach in terms of usability.

For reference, the previous approach in ComfyUI-Manager was based on the concept of simply changing the global preview_method state immediately.

In my opinion, the most natural approach is that, assuming a multi-user scenario, the preview should appear differently based on the preview_method configured for each user. Additionally, any changes to the settings should be applied immediately, even if the workflow execution is already in progress.

[huchenlei]

I understand the goal of having immediate preview updates and per-user configurations. However, storing this state on the server side introduces some important technical considerations:

1. Global server state creates challenges for horizontal scaling - if you need to run multiple server instances to handle load, they would need to synchronize this state across instances.

2. When state is managed server-side, you introduce potential race conditions and consistency issues in a multi-user scenario. For example, if two users modify the preview settings concurrently, the final state becomes unpredictable.

Instead, I'd suggest:

• Have each client maintain their own preview preferences locally
• Pass these preferences as part of each request (either in headers or request body)
• The server remains stateless and simply processes each request based on the provided parameters

This approach:

• Maintains clean separation of concerns (client handles UI state, server handles processing)
• Scales better horizontally since servers don't need state synchronization
• Provides natural isolation between different users' settings
• Still allows for immediate preview updates since the client controls when to send requests

For the specific workflow execution case - the client could include their current preview preferences with each status check request, allowing the server to return appropriately formatted previews without maintaining state between requests.

[ltdrdata]

To summarize, should I embed the preview method in the queue item so that the queue runs using that preview method?

[robinjhuang]

+1 Keeping the server stateless.

Having a preview_method in the /prompt payload makes sense to me. There is a downside of existing jobs will not have that preview reflected. But in some cases that might be desirable as well.