Incorrect 413 Request Entity Too Large on pg statement_too_complex

[steve-chavez]

Problem

Having an infinite loop on insert:

create table test.ins(
  id int
, name text
);

create or replace function ins()
returns trigger as $$ begin
  insert into ins values (NEW.id, NEW.name);
end $$ language plpgsql;

create trigger do_ins
after insert
on ins
for each row
execute procedure ins();

We reply with:

http POST localhost:3000/ins <<JSON
> {"id": 3, "name": "qwer"}
> JSON

HTTP/1.1 413 Request Entity Too Large
Content-Type: application/json; charset=utf-8
Date: Fri, 23 Feb 2024 21:32:00 GMT
Server: postgrest/12.1 (160caaf)
Transfer-Encoding: chunked

{
    "code": "54001",
    "details": null,
    "hint": "Increase the configuration parameter \"max_stack_depth\" (currently 2048kB), after ensuring the platform's stack depth limit is adequate.",
    "message": "stack depth limit exceeded"
}

Which is incorrect. In general because a 4xx is a client side error.

This is done on:

postgrest/src/PostgREST/Error.hs

Line 479 in 1a141c1

'5':'4':_ -> HTTP.status413 -- too complex

Solution

Reply with a 500 status instead for every 54xxx.

It's tempting to turn 54xxx into a 508 Loop Detected but maybe that's not correct for every case.

[wolfgangwalther]

Treating all 54xxx error codes as 413 seemed to be wrong. Why would treating all those as 500 instead be better?

The docs say this:

54000 program_limit_exceeded
54001 statement_too_complex
54011 too_many_columns
54023 too_many_arguments

Especially the last two look like they could be mapped to 4xx instead. Maybe we should investigate more to find out how to raise those errors.

In general, it might also be possible to look at the context of the raised error to determine whether the error occurred as part of our calling query or as part of some subprogram? Not sure about that.

[steve-chavez]

Treating all 54xxx error codes as 413 seemed to be wrong. Why would treating all those as 500 instead be better?

413 is totally misleading, some clients show it as 413 Payload Too Large. https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/413. 500 is not informative but at least not misleading.

Especially the last two look like they could be mapped to 4xx instead.
In general, it might also be possible to look at the context of the raised error to determine whether the error occurred as part of our calling query or as part of some subprogram?

Not really. I've seen those happen when there's dynamic SQL and there's some infinite loop which generates too many columns. Those are always a server side error but not our fault.

[steve-chavez]

Another example of the same with functions:

create function private.hi () returns text as $$ begin
  return test.hi();
end; $$ language plpgsql;

create function hi () returns text as $$
  select private.hi();
$$ language sql security definer;

curl localhost:3000/rpc/hi -i

HTTP/1.1 413 Request Entity Too Large
{"code":"54001","details":null,"hint":"Increase the configuration parameter \"max_stack_depth\" (currently 2048kB), after ensuring the platform's stack depth limit is adequate.","message":
"stack depth limit exceeded"}

508 Loop Detected looks apt for these.