Make Assets image generation async completely#1638
Conversation
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Here's a visual recap of what changed:
Open the full interactive recap |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Builder reviewed your changes and found 2 potential issues 🔴
Review Details
This incremental update addresses the previously reported picker/session issues and tightens the async image-run lifecycle, but it also changes provider fallback behavior in a way that materially affects non-Builder-managed deployments. The shared finalization path is a sound direction overall: centralizing completion logic, keeping the UI on processing instead of blocking, and teaching the picker to retain processing run IDs all improve the architecture.
Risk assessment remains standard / medium because this is cross-cutting generation/session/runtime logic rather than a cosmetic UI tweak.
New findings in this revision
- 🔴 HIGH The new single-shot helper now rejects manual Gemini/OpenAI fallback whenever a
runIdis present, butgenerate-image/generate-image-batchalways create a run first. That effectively breaks BYOK/manual image generation for the normal action path. - 🟡 MEDIUM Refresh finalization reuses the same tiny budget for both the provider request and the image download, so completed provider runs can get stuck returning
processingforever on slow downloads.
Good changes in this revision: the previous open issues around processing run IDs in the picker and missing session activation for all-processing batches now appear addressed, and the added tests cover those fixes.
🧪 Browser testing: Will run after this review (PR touches UI code)
Motivation
Hosted agent actions have a ~40s soft timeout, but image generation could hold the action open for much longer: a single managed provider call had a 90s request ceiling plus an internal multi-minute in-flight poll loop, and batches waited across multiple slots. Slow or large batches could therefore time out even though the provider kept generating successfully in the background.
Summary
generate-image/generate-image-batchreturn quickly when images are still processing