Skip to content

Timeout for large payload #174

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
2 tasks done
dthib opened this issue Jan 14, 2025 · 4 comments
Open
2 tasks done

Timeout for large payload #174

dthib opened this issue Jan 14, 2025 · 4 comments
Labels
bug Something isn't working

Comments

@dthib
Copy link

dthib commented Jan 14, 2025

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

When the payload is large, it does not reach the endpoint and seems stuck in pg_net until a timeout is reached. This is the case with the latest pg_net version (0.14.0) installed by default but is not the case on one production system using 0.7.x pg_net version.

To Reproduce

With latest supabase version.
I have searched for a while but now we are sure that it's not related to our api because we were able to reproduce it with https://webhook.site.

  1. Go to webhookt.site and create a endpoint
  2. Execute the query below
    select * from net.http_post(
    'https://webhook.site/11a266de-f1b6-48d9-9477-3aeb8c8098cc',
    '$PAYLOAD'::jsonb)
    by replacing $PAYLOAD with the joined json payload.

testpayload.txt

  1. Please note that the same query with a smaller payload is ok. Please not too that sending the payload directly to https://webhook.site using postman works too.

Smaller payload testpayload_works.txt

Expected behavior

Request beeing sent to the server

Screenshots

If applicable, add screenshots to help explain your problem.

System information

  • OS: macOs
  • Version of supabase postgres docker 15.8.1.020
  • pg_net installed 0.14.0

Additional context

I wanted to try other pg_net versions but I can't drop & reinstall the extension as the owner is supabase_admin.

@dthib dthib added the bug Something isn't working label Jan 14, 2025
@dthib
Copy link
Author

dthib commented Jan 25, 2025

Any help ? Have you been able to reproduce the bug ?
Thanks

@steve-chavez
Copy link
Member

Sorry, still haven't reproduced.

Our test suite is in python, @dthib If you'd like to speed up things and help, perhaps you could contribute a test?

Also see https://github.com/supabase/pg_net/blob/master/docs/contributing.md#development.

@steve-chavez
Copy link
Member

I can reproduce locally ✅ . Using this branch https://github.com/steve-chavez/pg_net/tree/174 and

$ nix-shell

$ net-with-nginx net-with-pg-17 psql
\set bigjson `cat test/data/big_payload.json`

select net.http_post(
            url:='http://localhost:8080/post',
            body:= :'bigjson'
        );

 http_post 
-----------
         1
(1 row)

# 127.0.0.1 - - [06/Mar/2025:18:31:03 -0500] "POST /post HTTP/1.1" 400 0 "-" "pg_net/0.14.0"

select * from net._http_response;
-[ RECORD 1 ]+----------------------------------------------------------------------------------------------------------------------------------------------------------------
id           | 1
status_code  | 
content_type | 
headers      | 
content      | 
timed_out    | 
error_msg    | Timeout of 5000 ms reached. Total time: 5000.687000 ms (DNS time: 0.077000 ms, TCP/SSL handshake time: 0.398000 ms, HTTP Request/Response time: 4999.976000 ms)
created      | 2025-03-06 18:30:58.929522-05

As seen above the request times out.

testpayload.txt

The json file is of size:

$du -sh test/data/big_payload.json 
208K    test/data/big_payload.json

Smaller payload testpayload_works.txt

The smaller json does work:

$ du -sh test/data/smaller_payload.json 
36K     test/data/smaller_payload.json
\set smallerjson `cat test/data/smaller_payload.json`

select net.http_post(
            url:='http://localhost:8080/post',
            body:= :'smallerjson'
        );
 http_post 
-----------
         1
(1 row)

# 127.0.0.1 - - [06/Mar/2025:18:38:29 -0500] "POST /post HTTP/1.1" 200 11 "-" "pg_net/0.14.0"

# select * from net._http_response;
-[ RECORD 1 ]+--------------------------------------------------------------------------------------------------------------------------------------------------------------------
id           | 1
status_code  | 200
content_type | application/json
headers      | {"Date": "Thu, 06 Mar 2025 23:38:29 GMT", "Server": "nginx/1.26.0", "Connection": "keep-alive", "Content-Type": "application/json", "Transfer-Encoding": "chunked"}
content      |                                                                                                                                                                    +
             | 
timed_out    | f
error_msg    | 
created      | 2025-03-06 18:38:29.129701-05

Although for some reason the content is empty when it should have the echoed body.

@steve-chavez
Copy link
Member

So when doing net.http_post, we use convert_to internally:

pg_net/sql/pg_net.sql

Lines 201 to 208 in 6051d8a

insert into net.http_request_queue(method, url, headers, body, timeout_milliseconds)
values (
'POST',
net._encode_url_with_params_array(url, params_array),
headers,
convert_to(body::text, 'UTF8'),
timeout_milliseconds
)

This convert_to goes through the following path:

There's a palloc at the last function. So looks we're doing a copy of the json body, which seems unnecessary. The extra processing there also slows down the whole process, which in the end causes the timeout.


To avoid the copy, I think we're going to have to store the input as text instead of bytea for the net.http_request_queue , maybe we need to revisit #27. It's possible we just need to add an extra column.

Additionally, converting the net.http_<method> functions to C might help too (related to #164).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants