staging → main: auto-promote c1f993c - #2359
Merged
Merged
Conversation
End-to-end coverage for the canvas-chat unblocker. Exercises every moving part of the #2339 stack against a real platform instance: Phase 1 — register a workspace as delivery_mode=poll WITHOUT a URL; verify the response carries delivery_mode=poll. Phase 2 — invalid delivery_mode rejected with 400 (typo defense). Phase 3 — POST A2A to the poll-mode workspace; verify proxyA2ARequest short-circuits and returns 200 {status:queued, delivery_mode:poll, method:message/send} without ever resolving an agent URL. Phase 4 — verify the queued message appears in /activity?type=a2a_receive with the right method + payload (the polling agent reads from here). Phase 5 — since_id cursor returns ASC-ordered rows STRICTLY AFTER the cursor; the cursor row itself must NOT be replayed. Sends two follow-up messages and asserts ordering: rows[0] is the older new event, rows[-1] is the newer. Phase 6 — unknown / pruned cursor returns 410 Gone with an explanation. Phase 7 — cross-workspace cursor isolation: a UUID belonging to one workspace cannot be used to peek at another workspace's feed (returns 410, same as pruned, no info leak). Idempotent: per-run unique workspace ids (date+pid). Trap-based cleanup deletes the test rows on exit; no e2e_cleanup_all_workspaces call (see feedback_never_run_cluster_cleanup_tests_on_live_platform.md). Wired into .github/workflows/e2e-api.yml so it runs on every PR that touches workspace-server/, tests/e2e/, or the workflow file itself — same gate as the existing test_a2a_e2e + test_notify_attachments suites. Stacked on #2354 (PR 3: since_id cursor). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
CI run on PR #2355 surfaced `pq: invalid input syntax for type uuid: ws-poll-e2e-1777529293-3363` — workspaces.id is UUID-typed and the hand-rolled "ws-<tag>" shape fails the cast. Phase 1 returned generic 'registration failed' which cascaded into Phase 3 'lookup failed' (resolveAgentURL on a non-existent row) and Phase 4 'missing workspace auth token' (no token extracted because Phase 1 didn't run the bootstrap path). Generate v4 UUIDs via uuidgen (with a python3 fallback), one each for the poll workspace, the caller workspace, and the Phase 2 invalid-mode probe. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…l-roundtrip test(e2e): poll-mode + since_id cursor round-trip (#2339 PR 4)
The auto-promote staging → main flow uses `gh pr merge --auto` with GITHUB_TOKEN, which means GitHub suppresses downstream `push` events on the resulting main commit. This is documented behavior — events created by GITHUB_TOKEN do not trigger new workflow runs, with workflow_dispatch and repository_dispatch as the only exceptions. Effect: when the merge queue lands the auto-promote PR, the main push DOES NOT fire publish-workspace-server-image. canary-verify + the :staging-<sha> → :latest retag never run, so redeploy-tenants-on-main also never fires. Tenants stay on stale code until someone manually dispatches the chain (which is what just happened for issue #2339). Fix here: after enqueuing auto-merge, poll for the PR to land, then explicitly `gh workflow run publish-workspace-server-image.yml --ref main`. workflow_dispatch is the documented exception, so the dispatch event itself DOES create a new run. canary-verify and redeploy-tenants-on-main chain via workflow_run as before. Long-term (tracked in #2357): switch the auto-merge call above to a GitHub App token (actions/create-github-app-token) so the merge event itself can trigger the downstream chain naturally; the polling tail becomes deletable. Why a 30-min poll cap: merge queue typically lands a green promote PR within 5-10 min. 30 min covers a slow CI run without hanging the workflow indefinitely. If the merge times out, the step warns and exits 0 — operator can manually dispatch as a fallback. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
github-actions
Bot
requested a review
from hongmingwang-moleculeai
as a code owner
April 30, 2026 06:35
…patch-chain fix(ci): dispatch publish chain after auto-promote merge (#2357)
HongmingWang-Rabbit
left a comment
HongmingWang-Rabbit
left a comment
Contributor
There was a problem hiding this comment.
Auto-promote LGTM mechanically: 32/32 checks SUCCESS, MERGEABLE, fast-forward of staging containing #2354 (poll-mode E2E test, 308+ lines) and #2358 (workflow fix, 3+ lines on e2e-api.yml). Both upstream changes were individually reviewed and approved on staging. Per loop policy, declining to auto-approve here only because the diff touches .github/workflows/e2e-api.yml — flagging for a human eye.
Contributor
Author
|
🔒 Auto-merge disabled — new commit ( |
3 tasks
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.
Automated promotion of
staging(c1f993ca) tomain. All required staging gates green at this SHA: CI, E2E Staging Canvas, E2E API Smoke, CodeQL.This PR is auto-generated by
.github/workflows/auto-promote-staging.ymlwhenever every required gate completes green on the same staging SHA. It exists because main's branch protection requires status checks "set by the expected GitHub apps" — directgit pushfrom a workflow can't satisfy that, only PR merges through the queue can.Merge queue lands this; no human action needed unless gates fail. Reverse-direction sync (the merge commit on main → staging) is handled by
auto-sync-main-to-staging.yml.