Observe the real deploy run in the mega harness#93
Merged
Conversation
The 2026-07-16 mega waited out its 420s deploy-run timeout while the deploy it was waiting for, deploy-poll-ea0bed35, had already succeeded. list_runs narrows its result to Run.user_id == caller for every non-admin X-Telegram-ID it sees, and a valid internal key does not lift that narrowing. pr_poller creates deploy runs with no user_id, so the harness user — which is not admin — was answered [] for the whole wait, whatever filter it passed. The contract suite faked /api/runs/ without that rule, so it stayed green. Observe deploy runs as a plain internal service with no user header, and pin the rule in an API service test against the real router. Look the run up by story: pr_poller stamps story_id on the run it creates, and a project can carry deploy runs of other stories. The returned run is checked against this mega's story and must carry a merged head_sha, so neither a foreign run nor an engineering-triggered one without a SHA can be mistaken for it. A user-scoped client is now rejected on the spot instead of polling a blind endpoint for seven minutes, and the fake runs API mirrors the ownership narrowing so this cannot pass unnoticed again.
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
1 participant
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.
The 2026-07-16 mega waited out its 420s deploy-run timeout while the deploy it was waiting for,
deploy-poll-ea0bed35, had already succeeded and reporteddeploy_outcome=success.Root cause
Not the
project_idfilter — that filter works.list_runsnarrows its result toRun.user_id == callerfor every non-adminX-Telegram-IDit sees, and a valid internal key does not lift that narrowing.pr_pollercreates deploy runs with nouser_id, and the harness user is not admin, so the harness was answered[]for the whole wait no matter which filter it passed. Reproduced against the live API with the failed run's own records:X-Internal-Key+X-Telegram-ID, any filter[]X-Internal-KeyonlyThe contract suite faked
/api/runs/without the ownership rule, so it stayed green over the blindness.Change
pr_pollerstampsstory_idon the run it creates, and a project can carry deploy runs of other stories. The returned run is also checked against this mega's story and must carry a mergedhead_sha, so neither a foreign run nor an engineering-triggered one without a SHA can be mistaken for it.Verification
tests/live/test_harness_contract.py66 passed.make test-service SERVICE=api104 passed, including the new service test.make test-unit,make lint,ruff format --checkclean.deploy-poll-ea0bed35,head_sha=6b5e543a…, typed outcomesuccess.No full live mega run and no cleanup of the saved resources — that is the PO's separate step after merge.