`timed_out` in `net._http_response` is always NULL

[diraneyya]

Bug report

• I confirm this is a bug with Supabase, not with my own application.
• I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

Both functions http_get and http_post on the pg_net extension offer a timeout parameter in milliseconds.

This parameter works (unlike mentions of it not working), and indeed the requests are halted when they take longer than this amount of time.

Since http request failure can occur for a variety of reasons, of which a timeout is one such reason, it is advantageous, and indeed the case, that a timed_out column exists in the schema of the net._http_response table.

However, and contrary to expectation, the value of this column is always null, even when the error_msg strictly states a timeout.

To Reproduce

with t as (
    select random(0, 100) as t1, random(0, 100) as t2
)
select
    net.http_get(
        url := 'https://postman-echo.com/get',
        params := '{"key1": "value", "key2": 5}'::jsonb,
        timeout_milliseconds := t.t1
    ) as req_id_get,
    net.http_post(
        url := 'https://postman-echo.com/post',
        body := '{"key1": "value", "key2": 5}'::jsonb,
        timeout_milliseconds := t.t2
    ) as req_id_post from t;

This gives:

req_id_get	req_id_post
7	8

Where net._http_response shows:

id	status_code	content_type	headers	content	timed_out	error_msg	created
7	NULL	NULL	NULL	NULL	NULL	Timeout of 72 ms reached ...	2025-04-10 12:41:50.712235+02
8	NULL	NULL	NULL	NULL	NULL	Timeout of 34 ms reached ...	2025-04-10 12:41:50.712235+02

Expected behavior

id	status_code	content_type	headers	content	timed_out	error_msg	created
7	NULL	NULL	NULL	NULL	TRUE	Timeout of 72 ms reached ...	2025-04-10 12:41:50.712235+02
8	NULL	NULL	NULL	NULL	TRUE	Timeout of 34 ms reached ...	2025-04-10 12:41:50.712235+02

Screenshots

NA

System information

• OS: Proxmox
• pg_net version: 0.14.0
• PostgreSQL version: 17

Additional context

I installed two triggers in pg_net tables, both on row level, before insert, for both request queue and response tables.

[steve-chavez]

Many thanks for the detailed report. Could you show what the full contents of the error_msg?

Timeout of 72 ms reached ...
Timeout of 34 ms reached ...

The extra details should help in determining in which stage of the HTTP request the timeout happens. (it would be helpful to know this, the timed_out filed might not be getting filled if the timeout happens at the first stage)

[diraneyya]

An example:

Timeout of 4000 ms reached. Total time: 4001.944000 ms (DNS time: 24.968000 ms, TCP/SSL handshake time: 244.459000 ms, HTTP Request/Response time: 3732.321000 ms)

Another one:

Timeout of 400 ms reached. Total time: 400.392000 ms (DNS time: 0.075000 ms, TCP/SSL handshake time: -0.075000 ms, HTTP Request/Response time: 400.139000 ms)

More examples:

• Timeout of 3 ms reached. Total time: 18.470000 ms (DNS time: 18.470000 ms, TCP/SSL handshake time: 0.000000 ms, HTTP Request/Response time: 0.000000 ms)
• Timeout of 47 ms reached. Total time: 48.034000 ms (DNS time: 18.715000 ms, TCP/SSL handshake time: 29.319000 ms, HTTP Request/Response time: 0.000000 ms)
• Timeout of 10 ms reached. Total time: 24.395000 ms (DNS time: 24.395000 ms, TCP/SSL handshake time: 0.000000 ms, HTTP Request/Response time: 0.000000 ms)
• Timeout of 23 ms reached. Total time: 24.601000 ms (DNS time: 24.601000 ms, TCP/SSL handshake time: 0.000000 ms, HTTP Request/Response time: 0.000000 ms)

My triggers are now working correctly and not crashing the worker, yet this is still not working. I hope this helps!

[diraneyya]

Unrelated question when anyone gets to look at this:

Does raise exception in triggers of pg._http_response, despite returning normal results, lead to crashing the pg_net worker?

[steve-chavez]

Does raise exception in triggers of pg._http_response,

@diraneyya You mean you're adding a trigger to the pg_net.http_response table? That in itself will be a problem, all the net tables are internal, you're not meant to attach triggers to them. Yes, they could cause failure.

If you really need to react once a response arrives, then #62 should be the solution (not implemented yet).

[diraneyya]

Yes that is what I mean. I am installing triggers on "before insert" on both internal tables and using that to track the progress state of my "jobs". So far, this has worked nicely.

I tried to add a trigger on "after delete" and that has broken down the queued request journey so I moved back from it. Additionally, my experiments revealed that the queued request is only deleted from the net.http_request_queue when the response is obtained, hence, the "after delete" event would not be useful in detecting the state when the request has been sent but no response has been received yet.

So with this simplification, my job buffer table stores a nullable boolean field is_completed that contains the following:

• null when the wrapper request function is called
• false when the associated pg_net request enters the request queue
• true when the associated pg_net response enters the response table, in which case the insertion is cancelled by returning NULL by the trigger function

It would be nice to be able to do such things without having to use triggers but it is what I have to work with for now, I guess.

I would like your thoughts about this and whether you think this won't work at scale, because then I would be in trouble, as I am building a scraping engine that must scale.

Additionally, I want to praise the team for this extension, I am very grateful for it and passionately using it at the moment. I have used the model above to even create an equivalent of setTimeout in Javascript, which schedules a dynamic procedure to be called with certain parameters after a certain duration in milliseconds. The sleep endpoint is deployed locally as an archaic cgi-bin bash script, which works reliably and requires no actual networking while being on the localhost.

Please feel free to comment and give your thoughts.

[diraneyya]

A question: is there anything in the current pg_net codebase that automatically removes triggers I attempt to install on these internal tables? I had to reinstall some triggers just now but I am unsure if this is something that I did or whether it is something that the extension did on its own.

[steve-chavez]

is there anything in the current pg_net codebase that automatically removes triggers I attempt to install on these internal tables?

There's not, but since triggers are not expected on the net db objects then a pause/restore on Supabase cloud will likely not consider them. So they can be lost.

[diraneyya]

I am not using Supabase or Supabase cloud, just pg_net in my own PostgreSQL database.

[diraneyya]

Dear @steve-chavez @laktek @rafael @tomashley can you please give me a clear answer on whether this is a bug or the intended behaviour?

I upgraded to 19.5.0 and I am still getting a timed_out value of NULL, with an error message like this one:

"Timeout of 500 ms reached. Total time: 500.531000 ms (DNS time: 0.168000 ms, TCP/SSL handshake time: 0.193000 ms, HTTP Request/Response time: 500.105000 ms)"

I am building an internal extension on top of pg_net and trying to see what behaviour is to be expected in the future.

[diraneyya]

I just noticed that in this new version, the value of the column is false when it is known that a timeout event did not occur. Hence this is sufficient for me and I will be closing this issue accordingly.

[steve-chavez]

Hey @diraneyya, this is not solved yet but #226 will do.

I just noticed that in this new version, the value of the column is false when it is known that a timeout event did not occur.

Yes, but on errors the timed_out column value is currently NULL not true.