Repository navigation
test(docker-model): admit workspace setup revisions for unprotected execution - #3801
Conversation
…xecution The Credential Proxy change (#2487) made every Compute Driver refuse a revision without a durable execution admission. The Docker workspace setup tests build their revisions by hand and had none, so both failed with 'Missing or unsupported durable execution admission' before Docker did any work. Give them the unprotected admission OCC records for Docker Compute, as the other hand-built revision fixtures do.
|
🦞👀 Pull request received. I will update this pull request when review starts. ClawSweeper review completeClawSweeper finished reviewing this revision. The review result is being finalized. |
|
Codex review: needs maintainer review before merge. What this changesThis PR adds the required unprotected execution admission to the shared Docker workspace setup revision fixture. Example: Run the Docker embedded workspace setup case.
Review scores
ProductKind: Test only · Worth it: Yes · Fix scope: Complete Regression provenancePossible regression — suspected (reviewed change). No predecessor PR is attributed. Merge readiness✅ Ready for maintainer review Keep open: this PR makes a focused, correct fixture repair that current main still needs, with no introduced defects found. Priority: P2 Before mergeNone. FindingsNone. Tests
Agent review detailsHow this fits togetherThe integration suite constructs Agent revisions and passes them directly to DockerComputeDriver, which validates admission before creating runtime containers and initializing workspace files. flowchart LR
A[Workspace integration cases] --> B[Shared revision fixture]
B --> C[Docker Compute admission validation]
C --> D[Workspace initializer]
D --> E[Runtime containers]
E --> F[File and lifecycle assertions]
Technical reviewBest possible solution: Land the fixture admission field while keeping unrelated Docker runtime and authentication repairs separate. Do we have a high-confidence way to reproduce the issue? Current-main source establishes the failure directly: both cases omit executionAdmission and call a Driver that rejects its absence; the PR reports matching before-and-after Docker results, but this review ran no tests. Is this the best way to solve the issue? The added value matches OCC admission and existing revision fixtures, repairs both cases through their shared owner, and preserves all workspace and fail-closed assertions. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning medium; reviewed against 36fb7180e5d1. Provenance checked
TestingProof path: in-process harness. SecurityNone. EvidenceWhat I checked:
Likely related people:
Review metrics
LabelsLabel changes:
Label justifications:
Rating scale6/6 🦀 challenger crab · 5/6 🦞 diamond lobster · 4/6 🐚 platinum hermit · 3/6 🦐 gold shrimp · 2/6 🦪 silver shellfish · 1/6 🧂 unranked krab. Overall follows the weaker of proof and patch quality; ✨ marks media proof (a screenshot, video, or linked artifact) that directly shows the changed behavior. WorkflowClawSweeper edits this one comment on every review. Comment Reviewed October 26, 2026, 8:12 PM ET / October 27, 2026, 00:12 UTC. |
Problem
The
docker-modellane (Full Integration, dispatch-only, so pull-request CI never runs it) fails on main. Both Docker workspace setup tests stop before Docker does any work:Since the Credential Proxy change (#2487), every Compute Driver refuses a revision without a durable
executionAdmission; Docker Compute callsassertExecutionReleaseAllowedinprepareRevision. These two tests build theirAgentRevisionby hand and never got the field.Change
Give the hand-built revision the admission OCC records for Docker Compute,
{ version: 2, mode: "unprotected" }(Docker Compute refuses protected execution), as the other hand-built revision fixtures do (tests/helpers/kubernetes-compute-real.mjs,compute-singleton-worker.mjs). Test-only; no product change.Not changed here (the lane stays red after this PR; each item is separate):
409 Deployment requires an explicit Harness authentication binding. That is the documented support boundary, not fixture drift: OCC requires a Harness authentication binding at deployment and Docker Compute rejects every binding (Docker Compute; testing guide: "Selected Agent cases currently fail at admission").stopRevision) waits for the previous Gateway's state lock and exits: Docker Compute force-removes the old Gateway, so its lock is never released. feat(compute): isolate Docker Gateway state and verify ownership before recovery #3355 works in this area.Verification
The lane is dispatch-only, so it ran with the CI lane steps (
prepare.mjs,run-tests.mjs run docker-model,cleanup.mjs) on a remote test VM with Docker 29.9.2 and a dummy model key:Risks
Low. Test-only, one fixture field. The tests still drive the real Docker Compute Driver against real containers.