Supabase RLS Infinite Recursion (42P17): The Hidden Bug (Simply Explained)

A Broken Login That Wasn't About Login At All

Picture this. A user logs into an app. The screen flickers and kicks them right back to the login page. They try again. Bounced again. On the third try the dashboard finally loads, except it's blank. Empty. Nothing works.

This happened on an app I built. And it cost me hours, because the problem was lying to me about where it lived.

When you see a login that keeps bouncing people out, your brain screams "this is a login problem." So that's where I went. I checked everything in the login system. The digital ID card the app hands out when you sign in? Fine. The bouncer at the door deciding who gets in? Working perfectly. The handshake that happens during sign-in? Clean.

Everything in the login system passed every test I threw at it.

Here's the lesson I want you to remember before I tell you the answer. The thing you can see is not always the thing that's broken. The login screen was the messenger. I spent hours yelling at the messenger.

The Real Problem Was Hiding Three Rooms Away

The actual bug was in the database. That's the warehouse where the app stores all its information about users, accounts, and who's allowed to see what.

When the dashboard loaded, it tried to grab the user's data from that warehouse. But the request came back broken. And here's the cruel part. When the app couldn't get the data, it assumed the user wasn't allowed in. So it threw them back to the login screen. They logged in fine, the dashboard tried again, the same break happened, and the loop closed on itself.

The login screen was innocent. The whole time.

I only figured it out when I stopped staring at the login code and looked at what the database was actually saying. There it was, in plain text, an error code called 42P17. The database had been telling me the answer the entire time. I just hadn't bothered to read the note it left.

Why the Database Choked

Let me explain what went wrong in normal-person terms.

In an app where many different companies share the same system, you need strict rules about who sees what. Company A should never see Company B's stuff. So I set up a rule on every table of data: "you can only see rows that belong to your own company."

That's a good rule. The problem was how I wrote it.

To check whether you belonged to a company, the rule had to look up your company in the same list it was protecting. So to read the list, it had to check the rule. To check the rule, it had to read the list. To read the list, it had to check the rule. Forever.

It's like asking a security guard "am I allowed in this room?" and the guard says "let me check the list inside this room." But to open the room, he needs to confirm you're allowed in this room. So he checks the list inside the room. And around and around it goes.

The database is smart enough to spot this loop and refuse to play. Instead of spinning forever, it stops and throws that 42P17 error. That's not a flaw. That's the database protecting you from a question that can never be answered.

The Fix Most People Get Wrong

The trap here is that the bad version looks completely correct. It reads fine. It passes review. It even works in a quick test with one user. It blows up later, in production, once you have real customers and real data. By then nobody connects the broken login to a rule nobody's touched in months.

I've seen this exact mistake more times than I can count. It's the natural thing a smart engineer writes. And it's wrong every single time.

The fix is to stop making the rule check the list directly. Instead, you hand that check off to a separate, trusted helper. The helper is allowed to look at the list without triggering the rule. It just answers a simple yes-or-no question: "does this person belong to this company?" The rule asks the helper, gets a clean yes or no, and moves on. No loop. No crash.

That helper has to be built carefully, because it has special permission to peek behind the curtain. So I keep it narrow. It answers one question and hands back one word. It can't leak anyone's data because it never returns data in the first place. That's the difference between a system that holds and one that quietly springs a leak.

The Bonus Trap That Looks Identical

While we're down in the basement, here's a second gotcha that causes the exact same bouncing login.

When you add users to the system directly, say to set up test accounts or move people over from an old system, the login machinery expects certain fields to be empty text, not "blank/missing." If you leave them truly empty instead of an empty string, the login chokes on those users. And how does that show up? As a bouncing login or a broken session.

Same exact symptom. Completely different cause. Both buried below the login system you'd instinctively blame.

That's the whole point. Two totally unrelated problems, one identical symptom. If all you know is the symptom, you'll waste hours digging in the wrong place both times.

Read the Note Before You Tear the House Apart

The symptom was a broken login. The bug was in the database. Every hour I lost came from one bad instinct: fixing what I could see instead of what was actually failing.

The discipline is boring and it works. Before you touch anything you assume is broken, go find the request that's actually failing and read what it says. The database told me the answer in plain English. I just had to look.

This is what real multi-tenant software actually involves. Not the clean demo where one person logs in and everything works. The weird, buried failures that only show up once you have real customers and real data, then disguise themselves as something completely different.

These are the traps I've already stepped in, so your customers never have to.

Ready to bring AI leadership into your company?

I work with a small number of companies at a time. If you're serious about AI, apply to work together and I'll review your application personally.

Apply to Work Together