Subject: HTTP Server Error: Infinite Recursion Detected in Policy for Relation "Profiles"

[hajarij]

Dear Supabase Support Team,

I’m encountering a persistent issue when trying to integrate Supabase with Lovable (a no-code AI tool). The error occurs when attempting to interact with the profiles table via the Supabase API, and it prevents proper communication between the two platforms.

Here are the details of the error:

Error Message:

bash
Copier le code
failed to call url https://ehwdnzkzoogxorncyyof.supabase.co/rest/v1/profiles?select=*&id=eq.7c630add-6ee2-44aa-b747-7804656955d0 with status 500 and statusText undefined
Error Response Body:

json
Copier le code
{
"code": "42P17",
"details": null,
"hint": null,
"message": "infinite recursion detected in policy for relation "profiles""
}
HTTP Status: 500 (Server Error)

URL Called:
https://ehwdnzkzoogxorncyyof.supabase.co/rest/v1/profiles?select=*&id=eq.7c630add-6ee2-44aa-b747-7804656955d0

Steps to Reproduce:
I am using Lovable, a no-code AI-powered tool, which integrates with Supabase for backend services.
When trying to query or interact with the profiles table, the HTTP request fails, and the error above is returned.
The error occurs consistently, and the server returns a status 500 with a message indicating "infinite recursion detected in policy for relation profiles."
Troubleshooting Attempts:
I verified that the table profiles exists and has the correct schema.
I reviewed the RLS (Row-Level Security) policies for the table and suspect that there may be an issue with the policies causing recursion.
I confirmed that the API key and authentication tokens used by Lovable are correct.
Additional Context:
This issue seems related to a conflict or misconfiguration in the profiles table's policies or recursive relationships.
As Lovable depends on Supabase’s API for backend operations, this error disrupts the workflow and prevents the application from functioning properly.
Request for Assistance:
Could you help identify what might be causing the "infinite recursion" error in the profiles table?
Are there specific RLS policy configurations or recursive relationships that could trigger this issue?
If possible, could you guide me on how to resolve or debug this issue effectively?
Thank you for your time and assistance. Please let me know if you need any additional information or access to troubleshoot further.

[GaryAustin1]

https://github.com/orgs/supabase/discussions/22336#discussioncomment-8953774

You are likely selecting from the same table in a select policy which then tries to run the RLS again on the select.

[MrFreePress]

+1
Same happening to me the last 4 days.
I've kept my front end on lovable and have deleted and built database new 3x and continue to end up with the HTTP error after having a smooth running project for 30 days prior.
I've taken care of the recursive issue by reducing RLS security but that only buys me a few iterations before error comes back.

(Lovable+Supabase)
This error repeats, what should I be looking for and where?

_```
This is an HTTP server error which means that the server or API you're trying to communicate with is not working properly.
Unfortunately this is not something that the AI can fix for you since we don't control the server that you're trying to communicate with.

[GaryAustin1]

You need to look in the Dashboard Postgres and/or API Gateway logs for the recursion error to see if it is from Supabase. The RLS recursion error would normally be consistent. There are I'm sure many other ways to get recursion in function calls and triggers.

You don't say if you are getting the RLS recursion or some other error message.

[MrFreePress]

Yes, RLS recursion eventually happens with each db reincarnation.
I've been able to resolve temporarily but the recursion comes back and/or the Status 500 error returns.

I can dump logs here if that's any help.

[GaryAustin1]

You will not get an answer from anyone unless you show the RLS that is failing and the specific error from the log.

It if is RLS recursion you have to fix the policy. Retrying will not make it go away. It is an error in your RLS policy code.

[GaryAustin1]

Having the part of the Postgres log entry for the error where it likely shows what the code was running in SQL would be the most helpful and then the actual policy code for the policy you think is involved.