Repository navigation
Conversation
HSS_ORCH_REAL_STAGES names stages whose real implementations run even with stage stubs on; the cpu alias covers every weightless stage and objects is refused without HSS_OBJECTS_DEVICE=cpu. run_stage publishes impl/<stage>.json under the pinned hss-stage-impl/v1 contract, and the result stage's inputs carry impl/. Docs in backend/docs/real-cpu-stages.md.
HSS_ORCH_REAL_STAGES treated a missing or blank SMP_ENVIRONMENT as dev, while Settings reads the same values as prod. An unconfigured production process could therefore mix real and stand-in stages. Only an exact "dev" now passes, matching Settings. The remote refusal compared HSS_ORCH_MODAL_REMOTE to "1" only; load_orch also accepts true/yes/on in any case. It now uses the same _flag parser. The cpu alias no longer includes dense, which falls back to model weights on photo-only packets, and is refused while VISION_EXTERNAL_CALLS is on, since reads and criteria would then make paid calls. The journey test now checks the markers the result stage receives in its work dir, rather than filtering run.artifacts after the run. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…markers Brings in the impl/<stage>.json marker writer from #297 (run_stage) and the fail-closed stage selection from Z3, so the result stage has markers to read. graph.py conflict: both sides add "impl/" to the result inputs; kept the Z3 side, which also documents the marker contract. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Stub runs never reached compose_result, so the runs whose stages are stand-ins published no stageImplementations, standIns or reviewer-page notice. The stub result now reads the markers through the composer stage_implementations (with itself recorded as a stand-in) before it sends verdict_ready, and shares the page sentence via stand_in_notice. The marker reader now refuses a marker whose stage is not a pipeline stage or differs from its filename, and one whose implementation is not the string real or stand-in, with impl_invalid naming the file. Before, objects.json naming reads could be overwritten by reads.json and hide a stand-in, and a list or object implementation raised TypeError. Fixes the open #294 threads at compose.py:225, :373 and :374. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Important Draft PR not reviewedDraft PRs are not automatically reviewed by default.
To automatically review draft PRs, update your CodeRabbit configuration: reviews:
auto_review:
drafts: true
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
@codex review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
@codex review |
|
Codex Review: Something went wrong. Try again later by commenting “@codex review”. ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
Zephyrus task Z4. Fixes the five open review threads on #294: stub runs never named their stand-ins, the runner published no markers, and the marker reader trusted each marker's
stage.Depends on #297 and Z3's branch
gpt-burst/1022z-bs-297-stage-guard(d915427). This branch merges that branch in (3b69f2c) for theimpl/<stage>.jsonmarker writer inrun_stage. Land #297 and Z3 first; until then this diff also shows their commits. The only conflict wasgraph.py, where both sides add"impl/"to the result inputs. I kept Z3's side.What was wrong
graph.py:266: [obvious-fleet] Backend: the result names which stages ran as stand-ins #294 made the result stage readimpl/, but nothing wrote the markers, so every stage came outunknown. [obvious-fleet] Backend: per-stage real selection with implementation markers #297's writer fixes that once merged.compose.py:225: withHSS_ORCH_STAGE_STUBSon, the result stage isstubs/result.py, which never callscompose_result. So exactly the runs whose stages are stand-ins had nostageImplementations, nostandInsand no reviewer-page notice.compose.py:374: the reader tookdoc["stage"]on trust. A typo added a bogus key, andobjects.jsonnamingreadsas a stand-in could be overwritten byreads.jsonsaying real, which hid the stand-in.compose.py:373: animplementationof[]or{}raisedTypeErrorinstead ofimpl_invalid, so the error lost the filename.What changed
backend/server/result/compose.py:356stage_implementations(was_stage_implementations) now refuses a marker withimpl_invalid, naming the file, in three cases: itsstageisn't a pipeline stage, itsstagediffers from the filename, or itsimplementationisn't the stringrealorstand-in. The caller now supplies the result stage's own entry throughresult_implementation.stage_impl_dir(:348) andstand_in_notice(:401) are shared with the stub.backend/server/orchestrator/stubs/result.py:23: the stub result reads the markers throughstage_implementations(..., result_implementation="stand-in")before it sendsverdict_ready. It writesstageImplementationsandstandInsintoresult.internal.jsonand puts the same stand-in sentence on its review page.result.jsonis unchanged.compose_resultitself, because that would replace the stub's fixedmanual_reviewanswer with a real composition over stub scene and verdicts. The stub shares the stand-in record, the marker validation and the page sentence instead.review/template.htmlrendersstand_in_notice.backend/docs/real-cpu-stages.mdsays what the result does with the markers.Tests (
backend/server/result/tests/test_stand_ins.py,backend/server/orchestrator/tests/test_stub_result_stand_ins.py)implementationare each refused by filename.impl/result.jsonstill records the callable that is composing now.placementas a stand-in,resultincluded, and names them on the review page.objects.jsonnamesreadsfails the result stage withimpl_invalidand sends noverdict_ready.Command:
cd backend && OMP_NUM_THREADS=1 .venv/bin/python -m pytest -q server/result/tests/test_stand_ins.py server/orchestrator/tests/test_stub_result_stand_ins.pytest_stage_selection.pyadded: 62 passed.Full suite, run once. pytest-xdist isn't in the lock, so it ran without
-n:cd backend && uv sync --locked && OMP_NUM_THREADS=1 uv run pytest -qgave 7 failed, 1561 passed, 16 skipped, 21 errors. None of these come from this change:tests/test_capture_cold_restart.py(ImportError: cannot import name 'load_receipt' from 'scripts.replay_capture') and 4 failures inserver/eval/tests/test_gates.py('FAIL' == 'KNOWN_FAIL', dated pins). The same two files on 8057732 give the same 4 failed and 14 errors. This branch doesn't touchscripts/,tests/orserver/eval/.tests/test_capture_real_downstream.pyareTimeoutErrorindrain_finalize, with machine load around 20. Rerun on its own, the file passes.uv run ruff check .passes.uv run ruff format --check .flags onlyserver/orchestrator/tests/test_greptile_followup.py, which this branch doesn't touch.Left: I didn't run the full suite on the parent branch, so the comparison above covers only the failing files. Nobody has reviewed this branch yet.
🤖 Generated with Claude Code