Insert into non-existing table raises empty APIErrror

[bukacdan]

Insert into non-existing table raises empty APIErrror

Description

Found this bug while using Supabase client, where I originally opened this issue.

If client.table("table_name") does not exist (e.g. typo), insert and upsert operations raise empty APIError.

To Reproduce

1. Create reference to non-existing table
2. Attempt to insert data
3. Raises empty error with no information provided.

 def __init__(self, client: AsyncClient, user: AuthUser):
        self.client = client
        self.repository = self.client.table("not_existing_table")
        self.user = user

        try:
            insert_response = await self.repository.upsert(
                [mod.dict() for mod in db_models],
                count=CountMethod.exact,
                on_conflict="id",
                default_to_null=False,
            ).execute()
        except APIError as e:
            logger.error(f"Failed to bulk insert", user=self.user.id, **e.__dict__)
            # HERE the error is empty

Expected behavior

The error should contain information about the table not present in the scheme.

Screenshots

System information

• OS: macOS
• Version of supabase-py: ^2.6.0
• Version of postgrest: 0.16.9
• Version of PostgreSQL: 15.6

[wolfgangwalther]

Could you please reproduce this with a plain curl call, showing the actual PostgREST response, i.e. without any client/supabase involved?

[wolfgangwalther]

Version of postgrest: 0.16.9

This is not a valid PostgREST version. Which version are you really using?

[bukacdan]

curl -H "apikey: $API_KEY" -H "Authorization: Bearer $API_KEY" "$DB_URL/rest/v1/non-existing-table"
{"code":"42P01","details":null,"hint":null,"message":"relation \"public.non-existing-table\" does not exist"}%

After trying to reproduce the issue with curl, I concluded that the error must be in the client code, not in PostgREST. Sorry for the false positive.

[bukacdan]

curl -X POST -H "Content-Type: application/json" -H "apikey: $API_KEY" -H "Authorization: Bearer $API_KEY" "$DB_URL/rest/v1/non_existing_table" -d '{"name": "John Doe", "email": "[email protected]"}'
{}%

Actually I have to reopen this issue, it persists if I use POST on non-existing table.

PostgREST version: 12.x (not sure, using hosted supabase, but they've announced PostgREST 12 support)

[wolfgangwalther]

Confirmed against our spec fixtures:

% curl -X POST -H "Content-Type: application/json" "localhost:3000/items" -d '{"name": "John Doe", "email": "[email protected]"}'
{"code":"PGRST204","details":null,"hint":null,"message":"Could not find the 'email' column of 'items' in the schema cache"}

% curl -X POST -H "Content-Type: application/json" "localhost:3000/non_existing_table" -d '{"name": "John Doe", "email": "[email protected]"}'
{}

[taimoorzaeem]

How should we handle non-existing tables? For example, in case of GET, we get:

$ curl -H "Content-Type: application/json" "localhost:3000/non_existing_table"

{"code":"42P01","details":null,"hint":null,"message":"relation \"test.non_existing_table\" does not exist"}

This is because in readPlan, we don't check the schema cache, and send this query directly to db and get this error. In case of mutatePlan, we check the schema cache and fail early with NotFound.

I am thinking of solving this by checking schema cache in readPlan as well and then add some details to the error json (maybe also add a TableNotFound error which is more specfic than the more broad NotFound)

[wolfgangwalther]

I am thinking of solving this by checking schema cache in readPlan as well

This is certainly the way forward. I think we discussed this when we added domain representations, @steve-chavez - ultimately we'd want to validate as much as possible before hitting the database in the future, right?