revert(cli): keep HeyGen API traffic on stable prod - #3202
Conversation
somanshreddy
left a comment
There was a problem hiding this comment.
Verified at d00271ce — both asks pass. ✅
Zero EF route injection. Grepped all four source files at head: heygen_route count = 0 in publishProject.ts, submitFeedback.ts, client.ts, and oauth.ts; heygenRoute.ts is deleted (404 at head); every withHeygenCanaryRoute(...) call is reverted to a plain header object and all imports of the helper are gone. So auth/token/refresh/revoke/code-exchange, API-key + OAuth via buildAuthHeaders (which also covers cloud + /v3/users/me), publish (all 3 callsites), and feedback all route to prod now — including the older pre-#3201 canary headers on publish/feedback.
No telemetry-canary overreach. Changed-files list is exactly the 10 EF-route files; none of the PostHog/rollout canary surface (core/src/canary.ts, canaryRegistry.ts, cli|studio/telemetry/canary.ts, check-canary-sunset.ts, de-canary-suite.sh, validate-release-channel.mjs) is touched. The two "canary" concepts stayed cleanly separated.
Nit (non-blocking, intentional): publishProject.e2e.test.ts's fetchPublicProject now calls fetch(url,) with a trailing comma after the headers arg was dropped — valid JS, format-clean.
Reads as a complete, correct reversal. LGTM on the verification; leaving the stamp to an authorized approver.
Summary
Normal HyperFrames CLI traffic now stays on stable EF prod. This reverts hyperframes#3201 and removes the older canary route injection from publish and feedback, so login, token lifecycle, API-key billing calls, cloud operations, publish, and feedback no longer depend on a pre-release backend deployment.
The repository now contains zero
heygen_routeinjections. The unrelated telemetry/PostHog canary rollout system is unchanged.Test plan
bun run --cwd packages/cli test— 2,581 passed, 3 skippedbun run --cwd packages/cli typecheckbun run buildheygen_routeaudit — zero matches