Supabase实时DELETE事件过滤功能失效问题咨询

这不是预期行为，问题大概率出在replica identity的配置生效逻辑或过滤条件的细节上。

核心原因 #

PostgreSQL逻辑复制中，DELETE事件的过滤需要依赖表的replica identity获取被删除行的原始字段值（比如你的id），Supabase才能据此判断是否触发回调。虽然你执行了alter table "test" replica identity full;，但以下几个容易忽略的点可能导致过滤失效：

• 配置生效时机：如果这条命令是在Supabase创建复制槽之后执行的，旧的复制连接不会自动应用新配置，需要重置复制连接才能生效。
• 类型/格式不匹配：rowId的类型和表中id字段类型不匹配（比如id是整数但rowId是字符串格式数字），或者UUID类型的id没有用单引号包裹，都会导致过滤条件失效。
• 插值错误：${rowId}没有被正确替换成目标值，导致过滤条件实际是无效的。

分步排查与修复 #

1. 重置replica identity配置
   • 先在Supabase控制台的「Database > Replication」页面，删除对应表的复制槽后重新创建；
   • 或者执行以下SQL强制刷新：

     ALTER TABLE "test" REPLICA IDENTITY FULL;
     SELECT pg_reload_conf();
     

2. 验证过滤条件格式
   • 打印插值后的过滤条件确认正确性，比如：

     console.log(`id=eq.${rowId}`);
     // 若id是UUID，需确保输出为id=eq.'xxxx-xxxx-xxxx'格式
     

3. 最小化场景测试
   • 用固定的已知存在的id值替换${rowId}（比如filter: 'id=eq.1'），分别删除目标行和其他行，验证是否只有目标行被删除时触发回调。

额外提示 #

如果你的表有主键，无需设置REPLICA IDENTITY FULL，设置为DEFAULT（即主键）即可，这样更高效且能保证DELETE事件过滤正常工作；同时要确认Supabase Replication设置中，test表的DELETE事件已被勾选。

内容的提问来源于stack exchange，提问作者regal beagl