fix(test): stabilize cloud mock e2e stack#7824
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
|
Claude encountered an error after 0s —— View job I'll analyze this and get back to you. |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| @@ -124,10 +123,162 @@ export function buildControlPlaneApp(options: ControlPlaneMockOptions): { | |||
| 401, | |||
| ); | |||
| } | |||
| return next(); | |||
| } | |||
| const auth = c.req.header("authorization") ?? c.req.header("Authorization"); | |||
| if (!auth?.startsWith("Bearer ") || auth.slice(7).trim() !== token) { | |||
| return c.json({ success: false, error: "Unauthorized" }, 401); | |||
| } | |||
| await next(); | |||
| }); | |||
There was a problem hiding this comment.
expectedAuxToken now fully bypasses bearer-token check
The middleware now returns next() immediately after the aux token validates, so the bearer token is never checked when expectedAuxToken is set. The JSDoc comment on ControlPlaneMockOptions.expectedAuxToken still reads "in addition to the bearer token", which is now incorrect. Any caller that sets both options expecting dual-token enforcement will silently get single-token enforcement — requests carrying only the aux token will be accepted with no bearer at all.
Post-merge of #7824: - Mock control-plane was returning next() after aux-token match, skipping bearer auth entirely. Now requires both when expectedAuxToken is set, mirroring the real impl's dual-token auth so the harness still catches bearer-missing regressions. - BLOB binding in cloud-api-hono-dev only stubbed get/put/delete. list, head, and multipart now throw explicit "not implemented" errors instead of returning undefined, so latent route changes fail loudly in dev. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2 participants
Summary
Mock-stack E2E)./provisioncontract.x-eliza-cloud-database-url, and accept the internal sidecar token forwarded by the API.Validation
bunx @biomejs/biome check .github/workflows/cloud-e2e.yml packages/scripts/cloud/admin/dev/cloud-api-hono-dev.ts packages/test/cloud-e2e/src/fixtures/stack.ts packages/test/cloud-e2e/src/helpers/provisioning.ts packages/test/cloud-e2e/tests/deprovision.spec.ts packages/test/cloud-e2e/tests/provision.spec.ts packages/test/cloud-e2e/tests/stuck-cleanup.spec.ts packages/test/cloud-mocks/src/control-plane/server.ts packages/test/cloud-mocks/package.json packages/cloud-shared/src/db/client.tsgit diff --checkbun run --cwd packages/test/cloud-e2e typecheck && bun run --cwd packages/cloud-shared typecheckCI=true timeout 12m bun run cloud:e2e-> 4 passed in 28.9s on latestorigin/developNote
packages/test/cloud-mocks/test/control-plane.test.tscurrently hangs underbun testin this checkout even when filtered to a single public health test, so I did not use that standalone unit file as the ship gate. The CI blocker this PR targets is the full mock-stack E2E workflow, which now passes locally.Greptile Summary
This PR stabilizes the mock-stack E2E suite by replacing Wrangler dev with a local Bun/Hono launcher for the cloud-api subprocess, running DB migrations before API startup, and teaching the control-plane mock to process DB-backed provisioning/delete jobs when the API forwards
x-eliza-cloud-database-url. Teardown ordering is also fixed so process-level pg/PGlite pools are drained before the PGlite TCP bridge is killed.cloud-api-hono-dev.ts: Runs the same Hono app as the Worker under Bun, providing an in-memory blob store and no-opExecutionContext; the production Cloudflare Worker path is untouched.closeDatabaseConnectionsForTests()inclient.ts: WeakMap-backed closer registry lets test harnesses explicitly drain PGlite/pg pools before tearing down the ephemeral PGlite server.processDbBackedJobsin the control-plane mock: Dynamic imports from@elizaos/cloud-sharedallow the mock to claim and complete real DB provisioning/delete jobs, with the sidecar token (x-container-control-plane-token) used as the sole auth check replacing the old bearer-only gate.Confidence Score: 4/5
Safe to merge — all changes are confined to test infrastructure and dev tooling; the production Cloudflare Worker and cloud-shared production paths are not affected.
The auth middleware in the control-plane mock now accepts requests carrying only the sidecar aux token, silently dropping the bearer-token check when
expectedAuxTokenis set, and its JSDoc still describes the old dual-token contract. The/cron/process-provisioning-jobsendpoint also returns structurally different response bodies depending on whether the DB-URL header is present. Both issues are in test-only mocks with no production exposure.packages/test/cloud-mocks/src/control-plane/server.ts — the auth middleware change and the divergent cron-tick response shapes.
Important Files Changed
closeDatabaseConnectionsForTests()for teardown harnesses. Logic looks correct and is scoped to test/dev paths.createCloudAgentandstartAgentProvisioninghelpers, aligning tests to the two-step create + /provision contract. Clean refactor with no logic concerns.Comments Outside Diff (2)
packages/test/cloud-mocks/src/control-plane/server.ts, line 39-45 (link)expectedAuxTokenis set it is the sole auth check; the bearer token is only used when no aux token is configured.packages/test/cloud-mocks/src/control-plane/server.ts, line 370-380 (link)/cron/process-provisioning-jobsresponse shape diverges between the two code pathsWhen
x-eliza-cloud-database-urlis present the handler returns{ claimed, succeeded, failed, errors }(fromprocessDbBackedJobs); when absent it returns{ processed, failed, skipped }(fromtick()). The same endpoint now emits structurally different payloads depending on a runtime header. Current tests don't inspect the body, so this is silent today — but any future consumer that introspects the result will need to know which path was taken.Reviews (1): Last reviewed commit: "fix(test): stabilize cloud mock e2e stac..." | Re-trigger Greptile