Supabase 的 logs.all 端点明天（9 月 23 日）下线，脚本会直接报错

明天（9 月 23 日，周三）是 Supabase 给的最后一天。

logs.all 这个 Management API 端点在 7 月 23 日公告、9 月 23 日对所有项目移除。原文写得很干脆：只有直接调用 .../analytics/endpoints/logs.all 的才受影响，包括任何直接调它的脚本、集成和工具；不用它的人什么都不用做，Dashboard 里的 Logs Explorer 不受影响。

先判断自己中没中

三条快速判断：

1. 代码里搜 logs.all。只要出现过，明天就停。
2. 用了 Supabase MCP 并且让 agent 调过 get_logs——这个工具内部走的就是 logs.all。官方给的修复是把 mcp-server-supabase 升到 v0.10.0，升完不用改别的。
3. 只在 Dashboard 看日志、或者日志是接第三方可观测平台的，可以关掉这篇。

改法

路径换掉：analytics/endpoints/logs.all → analytics/endpoints/logs。

然后 SQL 要重写，因为新端点只接受 ClickHouse SQL，并且所有来源合成了一张 logs 表，不再一个来源一张表。原来 FROM edge_logs 要变成 FROM logs WHERE source = 'edge_logs'。

嵌套字段也换了位置：以前要逐层 CROSS JOIN unnest(metadata)，现在直接从 log_attributes 这个 map 里按键取，log_attributes['request.method']、log_attributes['request.headers.x_real_ip'] 这样，join 全部消失。

三个照抄公告会踩的坑

• 公告示例代码写的是 source_name，官方文档现行示例和查询面实际用的是 source。照抄公告不报错，只返回空。
• log_attributes 里的值全是字符串，比数字要先 toInt32OrZero() 转一下，而且它把缺失值也转成 0，别把那个 0 当真。
• MCP 和 API 调用方必须自己带有界的时间范围，超过 24 小时要拆成多个窗口分别取。

今天该做的

1. 全仓库搜一遍 logs.all，把命中位置列出来。别只搜主仓库，CI 脚本和一次性运维脚本里最容易藏。
2. 有 MCP 的，升 mcp-server-supabase 到 v0.10.0，然后把 agent 的日志工具调用切到 query_logs（execute_sql 是查 Postgres 的，不查 ClickHouse 日志）。
3. 迁移完别用”跑通了”验收。挑一个已知事件（手动打一次 404 就行），新查询必须在 5 分钟内查到它——查不到说明字段名写错了，不是”那段时间没日志”。

泼冷水

真正危险的从来不是那个你天天用的脚本，而是那个半年前写的、跑在 cron 里、没人看输出的一次性任务。它明天开始会安静地失败，而且大概率没有告警。今天花十分钟搜一遍 logs.all，比下个月排查”为什么日志里缺了三周数据”便宜得多。

原文：https://supabase.com/changelog/48235-migration-of-supabase-management-api-logs-all-analytics-endpoint-to-logs-endpoint