test(meshjob): gate tc16 on real job status instead of a fixed 8s sleep

[dhyansraj]

Summary

Both tc16 variants slept a flat 8 seconds waiting for a long-running job, then asserted it was completed. Under --parallel 8 the job outlives that budget and the bystanders read status=working:

assertion 4 (bystander-x should read the actual completed status (no auth gating))
  failed: does not contain "\"completed\""

Failed in 2 of 3 full parallel runs; passes scoped — which is what made it look flaky rather than under-specified.

The Java twin already had this exact gate (uc23/tc16 ~line 141), which is precisely why it never failed. Python and TypeScript were the outliers, so this brings all three into line rather than introducing a new pattern.

Two things beyond "wait longer"

It polls via the consumer, not a bystander. The bystanders reading job status without auth is the assertion under test — polling through one would pre-empt the very thing being proven. The comment says so, so a future editor doesn't "simplify" it.

It distinguishes a broken job from a slow one. Previously, a job that genuinely failed produced the identical message as one that was merely slow — does not contain "completed" — with the case timeout cutting off any diagnostics before they landed. The gate now exits immediately on failed/cancelled with the response body, dumps the last status and the provider log tail on timeout, and the case timeout moves 120 → 180 so that output can actually surface.

That second point is why this isn't just a flake fix: the old failure mode was uninformative by construction.

Verification

Full suite at --parallel 8: 559 passed, 0 failed, 9 skipped.

[PASS] uc21_meshjob/tc16_third_party_can_read_status        (38.9s)
[PASS] uc22_meshjob_ts/tc16_third_party_can_read_status_ts  (50.4s)
[PASS] uc23_meshjob_java/tc16_third_party_can_read_status_java (120.0s)
[PASS] uc20_tutorial/tc11_day10_bonus_streaming             (303.4s)

Assertions 4 and 5 are unchanged — they are the point of the test.

Follow-up, not in this PR

46 steps across the meshjob suites use handler: wait, several standing in for real readiness conditions. tsuite 0.7.0 ships a probe handler (interval, timeout, until, success_threshold, on_failure) that the suite uses nowhere today. Worth migrating as one reviewed change — on_failure alone would have short-circuited two separate investigations today by attaching meshctl logs <agent> | tail -50 to the failure output.

Boundary for that work: probe belongs on infrastructure readiness — agent serving HTTP, registry answering, job reaching terminal state — and never on dependency or provider resolution. The settling window (#1193) exists so integration tests don't wait on DI, and a probe waiting for the mesh to converge would have hidden #1456 entirely. That test failing is what surfaced a real runtime race.

Closes #1458

Summary by CodeRabbit

• Tests
  • Improved mesh job status test reliability by polling for completion instead of relying on a fixed wait.
  • Added clearer handling for failed, cancelled, and timed-out jobs.
  • Enhanced timeout diagnostics with captured status details and provider logs.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 1cc981d6-310c-4bea-b61c-ff43fd9239ef

📥 Commits

Reviewing files that changed from the base of the PR and between ae4c19d and 80c18d9.

📒 Files selected for processing (2)

• tests/integration/suites/uc21_meshjob/tc16_third_party_can_read_status/test.yaml
• tests/integration/suites/uc22_meshjob_ts/tc16_third_party_can_read_status_ts/test.yaml

---

📝 Walkthrough

Walkthrough

The Python and TypeScript MeshJob status tests replace fixed 8-second waits with consumer-side polling gates. They detect completion, failed or cancelled jobs, and timeout diagnostics. The Python test timeout increases from 120 to 180 seconds.

Changes

MeshJob status polling

Layer / File(s)	Summary
Consumer-side completion gates tests/integration/suites/uc21_meshjob/tc16_third_party_can_read_status/test.yaml, tests/integration/suites/uc22_meshjob_ts/tc16_third_party_can_read_status_ts/test.yaml	Both tests poll __mesh_job_status until completion. They fail immediately for failed or cancelled states and report status and provider logs on timeout. The Python test timeout increases to 180 seconds.

Estimated code review effort: 2 (Simple) | ~10 minutes

Possibly related PRs

• dhyansraj/mcp-mesh#1079: Introduces the TypeScript mesh.jobs.status facade used by the polling test.
• dhyansraj/mcp-mesh#1234: Covers MeshJob status handling for failed, cancelled, and stale-job scenarios.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly summarizes replacing the fixed 8-second wait with real job-status polling in the meshjob tc16 tests.
Linked Issues check	✅ Passed	The changes satisfy issue #1458 by adding consumer-side status polling, terminal-state handling, diagnostics, and the 120-to-180-second timeout increase.
Out of Scope Changes check	✅ Passed	The changes are limited to the two Python and TypeScript tc16 tests and implement the linked issue objectives without unrelated scope.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/1458-tc16-status-gate

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}