fix(verify): make Slack delivery work in the cloud sandbox - #1401
Conversation
Deploying the schedule surfaced two defects that only appear in the cloud environment, so no local run would have caught them. 1. The sandbox injects CLOUD_API_ACCESS_TOKEN, not CLOUD_API_TOKEN (see the env bundle in cloud's bootstrap/launcher.ts), but @relayflows/slack-primitive reads only CLOUD_API_TOKEN. Every scheduled run would have failed Slack delivery with auth_token_missing. github-primitive already falls back RELAY_CLOUD_API_TOKEN -> CLOUD_API_ACCESS_TOKEN; slack-primitive does not, so the workflow bridges it with the same precedence. 2. ENV_DEFAULTS assigned the cloud variables without exporting them, so the node child that posts to Slack saw only the original process env and the fallback above had no effect. CLOUD_API_URL and CLOUD_API_TOKEN are now exported. Defect 2 also means the earlier stub-server verification passed only because CLOUD_API_TOKEN was set directly in that test's environment; it would not have worked in the sandbox. Verified against a stub server for all three cases: ACCESS_TOKEN-only now posts with the right bearer, a directly-set CLOUD_API_TOKEN still posts, and neither configured still fails loudly with the payload echoed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Bugbot is not enabled for your account, so this pull request was not reviewed. Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughBoth feature workflows now populate missing cloud API tokens from fallback environment variables and explicitly export the cloud API URL and token for Slack delivery child processes. ChangesSlack credential environment bridge
Estimated code review effort: 2 (Simple) | ~10 minutes Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 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 |
Why
Deploying the nightly schedule (#1392) surfaced two defects that only appear in the cloud sandbox, so no local run — including my own stub-server verification — would have caught them.
1. The sandbox's token variable has a different name
packages/core/src/bootstrap/launcher.tsin../cloudinjects:but
@relayflows/slack-primitivereads onlyCLOUD_API_TOKEN:So every scheduled run would have failed Slack delivery with
auth_token_missing.@relayflows/github-primitivealready knows about this and falls backRELAY_CLOUD_API_TOKEN → CLOUD_API_ACCESS_TOKEN → WORKSPACE_TOKEN; the Slack primitive simply doesn't. The workflow now bridges it with the same precedence.2. The variables were never exported
ENV_DEFAULTSassigned the cloud variables but didn't export them. The Slack post runs in a node child process, which therefore saw only the original process env — so the fallback in (1) would have had no effect even once added.This one is worth calling out: my earlier verification of the Slack path against a stub server passed only because that test set
CLOUD_API_TOKENdirectly. It would not have worked in the sandbox. A green signal that didn't prove the thing it appeared to prove — the exact failure mode this whole workflow exists to catch, reproduced in my own test.Verification
Stub server, all three paths:
CLOUD_API_ACCESS_TOKENonly (sandbox shape)SLACK_POSTED· stub sawBearer access-tokCLOUD_API_TOKENonly (no regression)SLACK_POSTED· stub sawBearer direct-tokSLACK_ERROR auth_token_missing+ payload echoed, still loudBoth workflows
Validation: PASS, all step bodies passsh -n, prettier clean.Deployment note
The live schedule
29fe661bcurrently runs the #1392 content, which has this gap — tonight's 03:00 UTC run will produce its verdict and the relay-native#relay-healthreport normally, but Slack delivery will printSLACK_UNDELIVEREDwith the payload in the run log rather than posting toC0AEKNLDNKW. I'll re-deploy the schedule from main once this merges.🤖 Generated with Claude Code