Skip to content

Unblock integration CI: stop leaking task defs, drop exact-404-wording assert - #475

Closed
ling-senpeng13 wants to merge 3 commits into
fix/pin-mcp-below-2from
fix/relax-deleted-workflow-404-assert
Closed

Unblock integration CI: stop leaking task defs, drop exact-404-wording assert#475
ling-senpeng13 wants to merge 3 commits into
fix/pin-mcp-below-2from
fix/relax-deleted-workflow-404-assert

Conversation

@ling-senpeng13

@ling-senpeng13 ling-senpeng13 commented Aug 12, 2026

Copy link
Copy Markdown
Contributor

Two things break integration CI on every branch, neither from the code under test.

1. Server changed its 404 wording. test_all required exactly workflow with id: <id> not found.; the server now says No execution found for id: <id>. Assert the durable part — a 404 naming the execution.

2. The sdkdev account hit its task-def cap.

402 System has reached the maximum allowed Task Definitions limit of 1000.

Three suites register RUN_ID-suffixed task defs via worker_task(register_task_def=True) and never remove them — ~11 leaked per run, across four jobs, on every PR. Added best-effort tearDownClass cleanup (test_lease_extension had no tearDownClass at all).

This stops the leak but does not free the 1000 defs already registered, so CI stays red until someone with sdkdev credentials runs scripts/prune_leaked_test_task_defs.py --delete (dry run by default; only matches the suites' own prefixes + a run id).

@ling-senpeng13
ling-senpeng13 marked this pull request as draft August 12, 2026 21:30
@ling-senpeng13 ling-senpeng13 changed the title Stop asserting the server's exact 404 wording for a deleted workflow Unblock integration CI: stop leaking task defs, drop exact-404-wording assert Aug 12, 2026
test_all asserted the deleted-workflow 404 read exactly
"workflow with id: <id> not found." The server now returns
"No execution found for id: <id>", so the test fails on every branch
(reproduced on fix/pin-mcp-below-2 and fix/13-hierarchical-agents-demo;
main last went green Aug 7, before the change).

Assert the durable part instead: a 404 whose message names the execution.
The sdkdev account has hit its cap:

  402 System has reached the maximum allowed Task Definitions limit of 1000.

so registration now fails for every branch, and test_05_verify_task_definitions
404s on the def that could not be registered.

Three suites register RUN_ID-suffixed task defs via
worker_task(register_task_def=True) and never remove them, leaking ~11 per run
across all four integration jobs: test_comprehensive_e2e (5 tasks + 1 workflow),
test_async_lease_extension (4 + 4), test_lease_extension (2 + 2, which had no
tearDownClass at all). Cleanup is best-effort — a failed unregister warns rather
than reddening a passing suite.

scripts/prune_leaked_test_task_defs.py clears the backlog already on the server;
this stops the leak but cannot free the 1000 defs already there. It is a dry run
unless given --delete, and only matches the suites' own prefixes followed by a
run id, so no hand-registered def is a candidate.
Unregistering on teardown stops the leak but cannot free the ~1000 defs
already registered, so the account stays at its cap and every branch keeps
getting 402 on registration — no run gets far enough to clean up after
itself. Prune the stale leftovers before any test registers.

Only names matching an integration suite's prefix followed by a run id are
candidates, and only ones older than 2h: four buckets run in parallel against
one server, so a def a concurrent run may still be using is off limits (as is
one with no createTime, whose age is unknown). The reclaim prints how many it
freed, so a run that is still capped says so instead of failing obscurely.

Verified against a local server: reclaim deletes a registered
sync_basic_<run id> and reports the count; test_comprehensive_e2e (8 passed),
test_lease_extension and test_async_lease_extension pass with cleanup leaving
nothing behind; the deleted-workflow 404 assert holds on this server's third
wording of that message ("No such workflow found by id: <id>").

scripts/prune_leaked_test_task_defs.py now shares the matcher rather than
duplicating it, and grew --include-recent for pruning by hand when no run is
in flight.
@ling-senpeng13
ling-senpeng13 force-pushed the fix/relax-deleted-workflow-404-assert branch from 73255af to 071131e Compare August 12, 2026 22:05
@ling-senpeng13
ling-senpeng13 changed the base branch from main to fix/pin-mcp-below-2 August 12, 2026 22:05
@ling-senpeng13
ling-senpeng13 deleted the fix/relax-deleted-workflow-404-assert branch August 12, 2026 22:10
manan164 added a commit that referenced this pull request Aug 13, 2026
Folds in the remaining deterministic CI failure causes so one PR covers
all of them.

Task-def quota (402). The integration suites register per-run task defs
and never removed them, so on the shared server they accumulated to the
1000 cap and registration then answered 402 for every branch -- which is
also what produced the test_05_verify_task_definitions 404s. Adds
tearDownClass cleanup to the suites that leak, a conftest session hook
that reclaims what earlier runs already left behind, and a manual prune
script. Reclaim only touches names matching a known test prefix plus a
run id, and only those older than two hours, so a concurrent run never
has a def deleted from under it. Salvaged from the closed PR #475.

423 write contention. "Workflow is currently being updated, please
retry" is the server asking for a retry, but it is scoped to
retry_scenario only, not retry_on_transient: replaying a single
non-idempotent call (start_workflow, signal) risks double-executing a
write that landed and only contended on the read-back, whereas a
scenario re-runs from the top and rebuilds its own state.

Service registry 502. That suite called its scenarios bare, so one 502
from the proxy failed the whole run even though is_transient already
covers gateway 5xx. Wrapped in retry_scenario with the same shared
deadline the other aggregate suites use.

Not fixed: test_v2_fallback_intg "workflows did not complete in time".
It already retries transients, so this is completion timing, not a
transient API error -- possibly real 5.5.0 slowness. Raising its
deadline blind would hide that.
manan164 added a commit that referenced this pull request Aug 13, 2026
Nothing runs it. The conftest session hook already reclaims stale leaked
task defs, which is what actually keeps the account under its cap; the
script was a hand-run convenience that came along with the #475 salvage
and is not needed for CI to pass.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant