Feat/2081 - #367
Conversation
|
Claude finished @razasaddiqi's task —— View job E2E Coverage Review
Result: ✅ Approved — Journey 65 (Mentor Human Support Tab) adds 8 new covered checkpoints. Coverage files are accurate. |
mamigot
left a comment
There was a problem hiding this comment.
✅ E2E Coverage — All Good
New component feature is covered and coverage files are up to date.
Coverage check result: 586 → 594 checkpoints (+8) ✅
New journey added:
- Journey 65: Mentor Human Support Tab (
65-mentor-human-support-tab.spec.ts) - 8 checkpoints, all marked
covered
Coverage files verified:
e2e/coverage.json— new journey entry with correctsourceFilesandcheckpointse2e/COVERAGE.md— matching[x]checkpoint lines added
|
Claude finished @razasaddiqi's task —— View job E2E Coverage Review
Result: ✅ Approved — No new app routes introduced. Journey 65 (Mentor Human Support Tab) adds 8 new covered checkpoints. Coverage files are accurate. |
mamigot
left a comment
There was a problem hiding this comment.
✅ E2E Coverage — All Good
No new app routes were introduced. All existing coverage is intact.
Coverage check result: 586 → 594 checkpoints (+8) ✅
New journey added:
- Journey 65: Mentor Human Support Tab (
65-mentor-human-support-tab.spec.ts) - 8 checkpoints, all marked
covered
Coverage files verified:
e2e/coverage.json— new journey entry with correctsourceFilesandcheckpointse2e/COVERAGE.md— matching[x]checkpoint lines added
Resolved conflicts in e2e/COVERAGE.md, e2e/coverage.json, package.json, and pnpm-lock.yaml. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
PR E2E - OKFull report, traces and screenshots
|
GitHub keeps only ONE pending run per concurrency group. A third dispatch CANCELS the previously-pending one before it starts a single job — silently, with no diagnosis on the PR. os#390 was dropped exactly this way: #394 took the group, #390 queued, #367 arrived and evicted #390. Its check went red having tested nothing. This was masked while stg2 shared the load across two groups; pinning everything to stg1 made a three-deep queue routine. Two changes, and both are needed: Wait for a free dispatch slot before firing. The caller polls until no run for this env is queued/pending, so the pending slot is never contested. Costs nothing new — the caller already polls for up to 2h; this just moves the wait earlier, and prints 'N run(s) queued ahead' instead of failing silently. Retry on eviction. Two callers can still check simultaneously and both dispatch. A central run that ends 'cancelled' having started ZERO jobs is an eviction, not a result — re-dispatch (up to 3 attempts) rather than reddening the PR. Neither alone suffices: the wait has a residual race, and retry alone would let PRs thrash. Dispatch and wait merge into one step so the retry can span both. The gate now reads steps.dispatch.outputs.conclusion. The liveness guard (busy-vs-offline) and phase streaming are carried over unchanged.
Only .github/workflows/pr-e2e-tests.yml, copied from main. No other code from main is pulled in. A pull_request workflow runs from the MERGE commit, and this branch is 20 commits behind — so it would still run the caller as it was this morning: no wait-for-slot (would risk evicting a queued PR), and a 2h timeout that counts QUEUE time, which is exactly why this PR's last run reported no report link while its result was fine. Brings: ECR registry, wait-for-slot + stagger, eviction retry, orphan cancel, busy-vs-offline liveness guard, execution-only timeout, and the result-artifact download retry.
…n-cleanup fix (#399) The only conflict was .github/workflows/pr-e2e-tests.yml, where this branch carried a pre-fix copy of the CI caller. Resolved to main's version wholesale: the caller workflow is shared infrastructure, not part of this feature. Refreshing the merge ref is what makes the re-run actually use the fixed step — pull_request runs execute the workflow from the merge commit, so open PRs keep running the old one until main is merged in. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Checklist
Changes