Genarrative/.hermes/skills/genarrative-admin-backoffice/references/private-table-sql-token-refresh.md

本地 private table SQL 权限修复

场景：

• 后台或 api-server 通过 SpacetimeDB HTTP SQL 读取 tracking_event 这类 private table。
• 本地清库、重建 standalone 或重新发布模块后，原 CLI token 失效，SQL 可能报 no such table ... If the table exists, it may be marked private。

操作步骤：

1. 清空本地 SpacetimeDB 数据目录

   • 使用项目脚本停止本地实例后，备份或删除 server-rs/.spacetimedb/local/data。
   • 只清本地开发环境，不要误伤远端或其他 worktree。

2. 启动本地 standalone

   • 用项目约定的 scripts/dev-rust-stack.sh 或等价命令启动 spacetime。
   • 确认 /v1/ping 可访问后再取 identity。

3. 通过 /v1/identity 获取新 token 和 identity

   • 使用 POST http://127.0.0.1:3101/v1/identity
   • 只记录 identity，不要在日志中打印 token 明文。

4. 用新 token 登录 CLI

   • 运行：spacetime login --token <token>
   • 这会把 token 写到本地 CLI 配置，后续 HTTP SQL 可读 private table。

5. 重新验证 SQL

   • 使用带 token 的 POST /v1/database/<db>/sql
   • 先尝试 SELECT ... FROM tracking_event LIMIT 1
   • 若成功，再让 api-server 走同样 token。

6. 如果 api-server 需要复用 token

   • 优先读取项目内本地 CLI 配置中的 token，而不是硬编码或回填到 .env。
   • 输出日志时统一 [REDACTED]。

排查要点：

• ORDER BY 和 private table 是两个独立问题，先分开修。
• 清库后旧 token 很可能不再能看见 private table，不代表表不存在。
• 若 /v1/identity 返回的 token 没权限，再检查当前 standalone 是否就是刚启动的本地实例、database 名是否一致、模块是否已重新发布。