fix(cloud): prewarm selected sandbox image#3511
Conversation
|
😎 Merged directly without going through the merge queue, as the queue was empty and the PR was up to date with the target branch - details. |
|
React Doctor found no issues in the changed files. 🎉 Reviewed by React Doctor for commit |
|
There was a problem hiding this comment.
Purely additive optional fields propagated consistently through the pre-warm → lease → task-creation chain, mirroring the existing pattern for model/reasoningEffort. The cold-run path already had these fields; this PR adds the missing warm-activation counterpart. All new code paths are covered by tests.
Include cloud environment and custom image selections in warm requests and lease matching. Reuse only matching configured warm runs, preserve cold fallback, and ignore stale warm responses after the selection changes.
559c741 to
4e3c1d7
Compare
New commits pushed (delta classified non_trivial_delta) — stamphog approval dismissed; re-review running automatically.
There was a problem hiding this comment.
No showstoppers. Additive change that propagates two optional config fields through the pre-warm pipeline, fixes a latent out-of-order response race, and follows existing patterns throughout. Human reviewer approved, all bot concerns addressed and resolved, comprehensive test coverage added for warm, cold, debounce, and race-condition paths.
|
/trunk merge |
Thread the selected sandbox environment / custom base image through the mobile cloud-task warm path so a warmed sandbox matches what the task will actually run on. - `warmTask()` now optionally includes `sandbox_environment_id` / `custom_image_id` in the request body (only when set). - `useWarmTask` folds both ids into the debounce/dedupe key, so changing the selection re-warms, and forwards them to the warm call. - `runTaskInCloud` carries the ids on the run so a reused warm sandbox matches the selection instead of a mismatched default. Generated-By: PostHog Code Task-Id: 5c715645-baa3-460e-91ca-73ee7e7fad86
Problem
Cloud runs could reuse a prewarmed default sandbox even when the user selected a cloud environment or custom base image. This caused the run to start on the wrong sandbox configuration.
Why: Prewarming should remain available while respecting the selected VM image and environment.
Changes
Include the cloud environment and custom image in warm requests and warm-lease identity. Reuse a configured warm run only when its full sandbox selection matches, with cold provisioning as a safe fallback when no matching warm lease is available.
Ignore stale warm responses after the selection changes, so an older request cannot replace the lease for the latest image. Environments and explicit custom images are intentionally composable: the environment supplies its other settings, while the explicit image overrides its base image, matching cold-run behavior.
The corresponding backend support must enforce the same project/user access and image-readiness checks as cold runs before accepting these optional IDs. Backends that do not support them reject the warm request and the client safely falls back to cold provisioning.