Skip to content

Webhook debugging guide

注意：pg*net 0.10.0 版本已发布。如果你使用的是早期版本，应该考虑在基础设施设置中更新你的数据库。如果你不知道自己的版本，可以检查扩展面板。

调试步骤

1. 测试 Webhook 是否活跃： Webhook 是在 Postgres 后台工作线程中运行的。第一步调试就是看看工作线程是否在运行。运行以下 SQL 代码：

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

如果它没有返回整数，那么工作进程就失败了，需要重启。如果你使用的是 PG_NET 0.8 或更高版本，你可以通过执行以下函数来重启后台工作进程：

🌐 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:

1
select net.worker_restart();

否则，你需要在仪表板设置中快速重启你的实例。

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

2. 移除网络表上的所有触发器：

在大多数表上使用 pg_net 作为触发器没问题；不过，别在 net._http_response 或 net.http_request_queue 表上添加触发器。

🌐 Using pg_net in triggers on most tables is fine; however, do not add triggers to the net._http_response or net.http_request_queue tables.

net 表是特殊的，如果它们上的触发器失败或者调用 pg_net 函数（http_get、http_post、http_delete），可能会导致无限循环。这个警告对大多数项目来说没什么影响，但说明一下也无妨。

🌐 The net tables are special and if triggers on them fail or call a pg_net function (http_get, http_post, http_delete), it can lead to an infinite loop. This warning is irrelevant to most projects, but it's worth specifying in case.

3. 检查超时错误

注意：pg*net v0.11 已修复超时问题。在 Postgres 15.6.1.135 及以上版本可用。你可以在 基础设施设置 中升级你的 Postgres 版本。

去你的 表格编辑器 并导航到网络模式。它将包含两个表格：

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

  • _http_response
  • http_request_queue

_http_response 表保存过去 6 小时的所有响应消息。如果除了 id、error_msg 和 created 列之外，每一列都是 NULL 值，那么你遇到了 超时错误 。

🌐 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.

默认情况下，webhook 会执行接下来的 200 个可用排队请求。如果请求太密集，可能会导致大规模超时。在 Webhook 仪表板 中，你应该增加 webhook 的超时时间以尽量减少这个问题。

🌐 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. 检查端点 下面的代码通过 PG_NET 向 Postman Echo API 发送请求

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

然后 Postman 会用相同的负载进行回应。这是一个测试，用来确认请求是否被正确格式化并成功发送。

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

然后你可以在 表格编辑器 的 net._http_response table 中查看请求，或者使用以下 SQL：

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

1
select
2
*
3
from net._http_response
4
where id = <request_id>

你还应该检查过去6小时内所有失败的回复，看看是否有任何有见地的信息：

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

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

来自服务器的状态码在 Mozilla 的网络文档 中有说明

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

5. 创建日志

如果以上的建议都没有找出错误的原因，为了调试，写一个自定义的 webhook 来在 Dashboard 的 Postgres 日志 中创建日志可能会很有用。这个过程在 PG_NET 文档中有说明。

🌐 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.

结论：

如果你的问题仍然存在，请在 PG_NET GitHub 仓库 中将其记录为问题。你也可以通过你项目的 仪表板 联系 Supabase 支持以获取更多指导。

🌐 If your issue still persists, 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.