Persist cook phases before Lab dispatch#7901
Merged
Merged
Conversation
Contributor
Homeboy Results —
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #7891.
Fixes #7892.
Root cause
The controller created its durable Lab proxy only inside
exec_lab_context, after workspace materialization and dependency hydration had completed. During those Homeboy-owned setup phases, the caller's cook ID had no lifecycle record and status could not explain the active work or provider policy.Changes
materializing,hydrating, anddispatching.provider_state: pendingbefore model execution.How to test
cargo test controller_proxy_records_pre_execution_phase_progress -- --test-threads=1.cargo test core::agent_task_lifecycle::tests -- --test-threads=1.homeboy agent-task cook --runner <runner> --lab-only --run-id test-preflight ...against a workspace that requires materialization.homeboy agent-task status test-preflight --full.metadata.phaseasmaterializingorhydrating,metadata.provider_stateaspending, configuredmetadata.provider_rotation, the selected runner, and source checkout identity.dispatching, binds the runner child after daemon acceptance, and retains provider attempt history if rotation occurs.Verification
cargo fmt --checkpassed.cargo checkpassed.cargo test --lib: 7,171 passed, 34 failed, 18 ignored. The 34 failures are existing environment/baseline failures across extension discovery, fixture configuration, signal timing, and unrelated deploy/audit tests; the affected lifecycle suite is green.Backwards compatibility
Additive metadata only. Existing run IDs, runner handoff records, attempt history, and status consumers remain valid. Commands without an agent-task run ID do not create a proxy.
AI assistance