Webhook debugging guide

[TheOtherBrian1]

NOTE: version 0.10.0 of pg_net is out. You should consider updating your database in the Infrastructure Settings if you are on a prior version. If you do not know your version, you can check the Extensions Dashboard.

Debugging Steps

1. Test if webhooks are active:
Webhooks are run in a Postgresql background worker. The first debugging step is to see if the worker is active. Run the following SQL code:

select pid from pg_stat_activity where backend_type ilike '%pg_net%';

If it does not return an integer, then the worker has failed and needs to be restarted. If you are running PG_NET 0.8 or later, you can restart the background worker by executing the following function:

select net.worker_restart();

Otherwise, it is necessary to fast reboot your instance in the Dashboard's Settings.

2. Remove any triggers on net tables:

Please do not add triggers to the net._http_response and net.http_request_queue tables. If they fail or call pg_net's functions (http_get, http_post, http_delete) it can cause infinite loops. This warning is irrelevant to most projects, but it's worth specifying just in case.

3. Check for timeout errors

NOTE: The timeout issue has been patched in pg_net v0.11. It is available in Postgres 15.6.1.135 and above. You can upgrade your version of Postgres in the Infrastructure Settings.

Go to your Table Editor and navigate to the net schema. It will contain two tables:

• _http_response
• http_request_queue

The _http_response table saves all the response messages from the past 6 hours. If every column contains NULL values, except for the id, error_msg, and created columns, then you are experiencing a timeout bug.

By default, webhooks will execute the next 200 available queued requests. If the requests are too intense, it may result in a mass timeout. In the Webhook Dashboard, you should increase your webhook's timeout to minimize this issue.

4. Inspect endpoints
The below code makes a request to the Postman Echo API through PG_NET

select
net.http_post(
url := 'https://postman-echo.com/post',
body := '{"key1": "value", "key2": 5}'::jsonb
) as request_id;

Postman will then respond with the same payload. This is just a test to confirm that requests are being properly formatted and going through.

You can then view the request in the net._http_response table in the Table Editor or with the following SQL:

select
*
from net._http_response
where id = <request_id>

You should also inspect all the failed responses from the past 6 hours to see if their are any insightful messages:

select
*
from net._http_response
where "status_code" >= 400 or "error_msg" is not null
order by created desc;

Status codes from a server are described in Mozilla's web docs

5. Create logs

If none of the above suggestions uncovered the cause of the error, for debugging purposes, it may be useful to write a custom webhook that can create logs in the Dashboard's Postgres Logs. The process is outlined in the PG_NET documentation.

Conclusion:

If your issue still persists, please document it as an issue in the PG_NET Github Repo. You are also welcome to contact Supabase Support from your project's Dashboard for more guidance.

[vickkhera]

In your example 3, you may want to remove the markdown formatting of the URL.

Also, maybe mention something about timeouts and how an entire batch of requests as grouped by the net extension needs to finish within 2 seconds or every request in that batch will have a timeout error message.

[TheOtherBrian1]

@vickkhera Thanks for the insight. I updated the guide to reflect your suggestions