Merge button does nothing & cc.json upload fails with RLS error — duplicate profile cannot be consolidated

[B-EtterDigital]

Hey, hitting two issues that together leave me with a duplicate profile I can't fix from the UI.

Context

I have two entries on the leaderboard, both under the GitHub username B-EtterDigital:

1. Verified profile (rank interview with the best viberankers #32 at time of writing) — $9,426.66 / 5.3B tokens. Has the ✓ checkmark and bio "Cyrill Etter - B-etter.Digital DEV 1". Created previously by signing in via GitHub OAuth on the website.
2. Unverified duplicate (rank feat: minimal feature set #20 at time of writing) — $12,125.89 / 16.7B tokens. No checkmark, no bio. Created when I ran npx viberank from the CLI.

The CLI submission did not update the verified profile — it created a separate row.

Bug 1: Merge button does nothing

The site exposes a "Merge 2 submissions into one" → "Merge" button for this exact case. Clicking it produces no effect — no merge, no error message, no network response visible to the user.

Bug 2: Website cc.json upload fails with RLS error

To work around bug 1, I tried updating my verified profile directly via the website's cc.json upload (signed in with the same GitHub account that owns the verified profile). Upload fails with:

Failed to create submission: new row violates row-level security policy for table "submissions"

This looks like a Supabase RLS policy that doesn't permit the authenticated insert in this scenario — possibly because an unverified row with the same github_user already exists, or the policy is missing a clause for the OAuth-authenticated update path.

Request

Could you:

1. Server-side, delete the unverified duplicate row (rank ~20, $12,125.89 / 16.7B) and roll its stats into the verified B-EtterDigital profile (the one with the bio "Cyrill Etter - B-etter.Digital DEV 1").
2. Fix the RLS policy on submissions so authenticated users can submit/update via the website.
3. Fix the Merge button so users don't end up stuck like this in the future.

Happy to provide the request ID / network logs from the failed upload if useful — let me know.

Thanks!

[nikshepsvn]

Both bugs are fixed and deployed (commit f5f06eb). Same root cause for both:

Merge button doing nothing: the merge mutation was running browser-side with the Supabase anon key. RLS blocked the writes silently — anon clients can't write — and the UI showed success because the failures were never surfaced. Merge now runs server-side via a new /api/claim route under the authenticated session, with proper error propagation.

RLS error on cc.json upload: the website upload was also going browser → Supabase directly with the anon key (same pattern as #41). Web uploads now route through /api/submit like the CLI, which uses the service-role client.

For your specific account: rather than me touching prod data manually, the merge button itself should now work for you. If you sign in as B-EtterDigital and click Merge, it should consolidate the two rows into your verified profile. Could you give it a try and let me know whether it works? If anything still goes sideways, comment here with the response and I'll dig in.

Sorry for the bumpy experience.

[fourgit]

This looks more specific than a plain “missing INSERT policy” case.

You have two write paths that probably need to be modeled separately: the website cc.json upload by the GitHub-authenticated owner of the verified profile, and the merge/consolidation path for an existing unverified duplicate. If the RLS policy only covers “create a new submission” but not “update or merge the verified owner’s existing submission,” the UI can leave users stuck exactly like this.

I’m building FixRLS, a small Supabase RLS helper. For this case I’d test it as a submissions ownership/merge policy problem: generate the minimal INSERT/UPDATE policy shape, then produce a proof-of-fix checklist for:

1. same GitHub-authenticated owner can update their verified submission,
2. duplicate unverified row does not let another user hijack the profile,
3. merge path is handled server-side if it needs elevated privileges.

It uses placeholders only — no tokens, no Supabase keys, no request logs required.