fix(ui): CA processor cancellation
Summary
When a control adapter processor config is changed, if we were already processing an image, that batch is immediately canceled. This prevents the processed image from getting stuck in a weird state if you change or reset the processor at the right (err, wrong?) moment.
- Update internal state for control adapters to track processor batches, instead of just having a flag indicating if the image is processing. Add a slice migration to not break the user's existing app state.
- Update preprocessor listener with more sophisticated logic to handle canceling the batch and resetting the processed image when the config changes or is reset.
- Fixed error handling that erroneously showed "failed to queue graph" errors when an active listener instance is canceled, need to check the abort signal.
Related Issues / Discussions
Original report @JPPhoto https://discord.com/channels/1020123559063990373/1149506274971631688/1238153079950676101:
Also the global control adapter image doesn't get updated when setting processor to none
QA Instructions
- Add a CA layer
- Expand the advanced options
- Play around with the processor - select different processors, reset the processor, change the settings.
The debounce is 300ms, so if you time it right, you can trigger all possible behaviours, which I will not enumerate here bc its complicated. In short, no matter how your poke it, it should be responsive and not break.
With a processor selected, it should either be processing the image or showing the processed image. With no processor, it should be showing the original image. If you change the processor in any way while it is mid-processing, it should cancel the pending processing.
Merge Plan
n/a
Checklist
- [x] The PR has a short but descriptive title, suitable for a changelog
- [ ] Tests added / updated (if applicable)
- [x] Documentation added / updated (if applicable)