lovablelabs
🐞 Issue: Showcase Route Black Screen on /showcase/:id
Reported by: @3mof Date: 2025-07-07 Environment: Lovable Web App (Prod Link: showcase route) Severity: 🔥 Critical – demo-blocking error
🧩 Description The /showcase/:id route rendered a completely black screen despite valid athlete data being returned. This caused a stakeholder demo to fail and required over 17 AI and dev prompts to debug.
✅ Expected Behavior A public showcase route should:
Display the selected athlete’s showcase screen
Fallback gracefully if ui_skin is not set
Allow public rendering for users with visibility_level = 'public'
🐛 Actual Behavior Route rendered black screen
No visible error
No fallback UI skin
Silent failure if RLS blocks access
🔍 Root Causes RLS (Row Level Security) Block Supabase RLS enforced auth.uid() = user_id without exception for public users, blocking reads from the players table even if visibility_level = 'public'.
No ui_skin Fallback If athlete.ui_skin was null or undefined, ShowcaseRouter logic silently failed to render any content.
No Component Feedback Lack of debug output made it difficult to know if ShowcasePro or ShowcaseGamified were mounting at all.
🛠️ Fixes Applied
- RLS Policy Patch sql Copy Edit CREATE POLICY "Public players are viewable by everyone for showcase" ON public.players FOR SELECT USING (visibility_level = 'public');
- Fallback in ShowcaseRouter tsx Copy Edit const showcaseSkin = athlete?.ui_skin || uiSkin || 'professional';
- Debug + Safety Render tsx Copy Edit return showcaseSkin === 'professional' ? ( <ShowcasePro athlete={athlete} /> ) : ( <ShowcaseGamified athlete={athlete} /> ); 🧪 Repro Steps Visit /showcase/:id with a public athlete (e.g., visibility_level = 'public')
Without correct RLS or ui_skin fallback, screen goes black
No render confirmation from ShowcasePro or Gamified
🧯 QA Suggestions Add visual test or E2E smoke test for /showcase/:id
Log fallback render warnings in dev mode
Require all skin-dependent routes to include a UI skin fallback
Add public test user to Supabase QA environment
📌 Status ✅ Resolved (as of 2025-07-07)
🔄 Pending:
Internal review
Add to regression test suite
Communicate issue pattern to all module owners
Would you like me to submit this directly as a GitHub issue to your linked repo, or should I export it as a Markdown file for manual upload?
Ask ChatGPT
🧾 If You Want to Fix the Root Infrastructure
👉 Handoff to: Lovable DevOps / Backend Engineering Team
Specifically whoever manages PostgreSQL RLS policy enforcement and handles Supabase or auth-level table access rules.
-
Why: The missing RLS policy is the core failure.
-
Goal: Ensure that all
public-level data has matching read policies in every env (staging, prod, QA). -
Suggested Action: Add showcase smoke test and RLS validator in prelaunch pipeline.
🎨 If You Want to Improve Frontend Stability
👉 Handoff to: Lovable Frontend / Showcase Component Team
Specifically whoever owns the
/showcase/:idroute andShowcaseRouterorShowcasePrologic.
-
Why: No fallback skin, no debug failsafes, and no crashproof rendering.
-
Goal: Add better error boundaries and skin fallback defaults.
-
Suggested Action: Require default props or load-state visibility across all public-facing routes.
🔄 If You Want to Ensure This Never Happens Again System-Wide
👉 Handoff to: Roots QA + Product Infrastructure (ADB)
Whoever manages CI pipelines, smoke tests, and RLS rulebooks for white-labeled apps and cross-org logic.
-
Why: They set the rules for what “passes” before shipping.
-
Goal: Prevent policy regressions from reaching live builds.
-
Suggested Action: Add RLS regression tests + visual route audit for all
/showcase/:idpaths.
