[codex] Complete onboarding after first upload#2291
Conversation
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughAdds DB trigger functions that mark apps as onboarded on the first real app_version insert/update and clear onboarding data; updates the CLI to conditionally perform legacy-backend completion only when ChangesOnboarding automation and CLI gating
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Merging this PR will not alter performance
Comparing 
Footnotes
|
riderx
force-pushed
the
codex/complete-onboarding-after-upload
branch
from
557bc22 to
b5024df
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@supabase/migrations/20260518131054_complete_onboarding_after_first_upload.sql`:
- Around line 157-179: The function cleanup_onboarding_app_data_on_complete() is
declared but never attached to the apps table; add a trigger named
cleanup_onboarding_app_data_on_complete on public.apps so the function runs when
need_onboarding flips from TRUE to FALSE. Specifically, drop any existing
trigger with that name, then create an AFTER UPDATE OF need_onboarding trigger
ON public.apps FOR EACH ROW with a WHEN clause (OLD.need_onboarding IS TRUE AND
NEW.need_onboarding IS FALSE) that EXECUTE FUNCTION
public.cleanup_onboarding_app_data_on_complete(); this ensures the cleanup runs
on the intended transition.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: eb3fc5b9-70b2-4559-ad0e-37fff6094401
📒 Files selected for processing (4)
cli/src/init/command.tssupabase/migrations/20260518131054_complete_onboarding_after_first_upload.sqltests/onboarding-first-upload.test.tstests/security-definer-execute-hardening.test.ts
|
…ion apps The earlier commit on this branch closed the auto-fire path (the upload-driven trigger from PR #2291) but left a user-triggered path open: `capgo init` against an existing app with `need_onboarding = TRUE` still calls `completePendingOnboardingApp`, which flips the flag and fires `cleanup_onboarding_app_data_on_complete`, which calls `clear_onboarding_app_data` -- still wiping the app. Because the exact cohort described in #2295 is "apps provisioned via dashboard or CI without ever running `capgo init`," and the natural follow-up for those users is to run `capgo init` and pick "use existing app," that path needs a real safety check, not a circular "the only caller is `capgo init` so it's fine" argument. Add a production-safety guard at the top of `clear_onboarding_app_data(uuid, bigint)`. It refuses (RAISE WARNING plus early RETURN) when any of four independent indicators of real production usage exists: * any row in `public.devices` * any row in `public.channel_devices` * any row in `public.deploy_history` beyond the preserved version * any channel whose `version` is set and != the preserved version This is defense-in-depth at the function level: every present and future caller of either overload (`uuid` or `uuid, bigint`) is now protected, regardless of how the flag transition got triggered. Genuine onboarding placeholder apps -- the original intent -- pass the guard and are cleaned up as before. Refs: #2295
fix(onboarding): revert #2291 trigger that wipes production data
1 participant
Summary (AI generated)
Motivation (AI generated)
Apps created from the dashboard could stay stuck in onboarding when users skipped CLI init and uploaded from CI/CD. The onboarding flag was only cleared by CLI init, which made the app state depend on one specific setup path.
Business Impact (AI generated)
Users who create apps in the dashboard and upload from CI/CD now get moved into the normal app state automatically after their first upload. This reduces onboarding friction and prevents support issues caused by apps staying in setup mode after a successful upload.
Test Plan (AI generated)
Screenshots (AI generated)
Not applicable; backend and CLI state-management change only.
Checklist (AI generated)
Generated with AI
Summary by CodeRabbit
New Features
Bug Fixes
Tests
Chores