Files
Genarrative/server-rs/crates/spacetime-client
suzmii eeb345f2ad feat(游戏共创): 上架时即可指定共创授权档位(创建作品请求增量)
- TS 契约 `GameDistributionCreateGameRequest` 新增可选 `forkAuthorization?: GameDistributionForkAuthorization`,注释写明缺省禁止共创、非法值整请求 400、上架后只能单向提升
- Rust 契约同结构体新增 `#[serde(default)] pub fork_authorization: GameDistributionForkAuthorization`(非 `Option`):省略与显式传 `forbidden` 得到同一个值,**幂等摘要因此相同**——创建请求的摘要取自整个请求体,若写成 `Option` + `skip_serializing_if`,两种写法会变成「同 key 不同请求」而互相冲突;未知取值由反序列化直接拒绝
- api-server `create_game`:载荷改为 `Result<Json<..>, JsonRejection>`,拒绝统一映射成平台信封 400(与 `set_fork_authorization` 同修法),并按 rejection 文本区分文案(含 `forkAuthorization` → 「共创授权档位不合法,只接受 forbidden / nonCommercial / full」,其余 → 「创建作品请求字段不合法」;框架文本只用于选文案,不回传客户端);创建记录入参新增 `fork_authorization: fork_authorization_value(payload.fork_authorization)`
- spacetime-client:`GameDistributionCreateGameRecordInput` 新增 `fork_authorization: String` 并透传给 procedure;重新生成的 `GameDistributionCreateGameInput` 同步带上该字段
- spacetime-module:`GameDistributionCreateGameInput` 新增 `fork_authorization: String`;创建事务里用 `ForkAuthorization::parse` 解析,未知取值失败关闭(`FORK_AUTHORIZATION_UNKNOWN`,**不静默落成 forbidden**),并把原来的硬编码 `FORK_AUTHORIZATION_FORBIDDEN` 换成解析结果
- 资料编辑复用创建校验的转换函数与既有测试夹具按新字段补默认值;AGC 侧测试字面量同步(AGC 发布面板的 UI 接线留到后续,缺省值等价于不传)
- 测试:`create_game_request_defaults_fork_authorization_without_changing_digest`(缺省 → forbidden;显式 forbidden 与原缺省**摘要相同**;`nonCommercial` / `full` 原样保留;`"allowed"` 反序列化失败)与 `create_game_rejects_unknown_fork_authorization_with_envelope_bad_request`(未知档位 → 400 + 平台信封且无框架纯文本;非档位字段问题走通用文案;合法载荷不会被误拒——测试态发布灰度未配置,得到 503 而非 400,即证明载荷路径已通过且未触达创建)
- 文档:技术方案 §2.4(发布入口上架时即选档位)、§3.4(`POST /games` 请求增量补 `forkAuthorization`)、§3.9(补充说明上架指定档位已支持、事后提升仍保留)
2026-10-05 17:30:46 +08:00
..
2026-07-17 22:07:52 +08:00

spacetime-client 共享 package 说明

日期:2026-05-01

1. package 职责

spacetime-client 是 SpacetimeDB 客户端适配 package,后续负责:

  1. 生成 bindings 后的客户端访问封装
  2. Axum 与各模块对 reducer、view、订阅的调用适配
  3. 身份透传、连接配置与基础错误处理适配

在 DDD 重构中,本 package 只承接 WP-SC Spacetime Client:

  1. 把 SpacetimeDB 生成绑定转换成 api-server 可消费的 typed facade。
  2. 把 row snapshot / procedure result 转换成 BFF record。
  3. 统一 SDK 调用错误、业务 procedure 错误、缺失快照错误和超时错误。
  4. 不承载领域规则,不直接定义 table / reducer / procedure,不替代 spacetime-module。

当前约束见 ../../../docs/【后端架构】server-rs与SpacetimeDB数据契约-2026-05-15.md。

2. 当前完成口径

当前目录已不再只是占位。WP-SC Spacetime Client 在当前稳定 SpacetimeDB facade 范围内已经完成收尾:

  1. 通过 npm run spacetime:generate -- --rust-only 生成并纳管公开 Rust bindings。
  2. DbConnection 调用连接池、单一缓存读连接、握手等待、超时和断线清理已封装在 SpacetimeClient 内部;调用池不订阅 read model,HTTP 角色额外使用一条共享连接保存订阅行缓存。
  3. 已稳定的 assets、auth、AI task、Big Fish、Custom World、Puzzle、Runtime/Profile/Save、Story session、combat、inventory、NPC facade 均通过 typed 方法对外暴露。
  4. 生成绑定到 BFF record / module record 的 row snapshot mapper 已集中在 mapper.rs。
  5. SDK 调用错误、reducer 业务错误、procedure 业务错误、缺快照错误和本地输入校验错误已统一收口到 SpacetimeClientError helper。
  6. Story runtime projection source 已复用 runtime inventory typed facade,读取投影不再只依赖 runtime snapshot 中的历史背包 JSON 副本。
  7. Story runtime 投影读取会对历史 currentStory.options 做兼容推断:若旧快照缺少 scope,仍会按 functionId 通过 module-runtime-story 的 option helper 还原为 story / combat / npc 作用域,避免旧存档把读取链路卡死。

confirm_asset_object_and_return 与 bind_asset_object_to_entity_and_return 的调用必须等到 SDK on_connect 回调后再发起。DbConnection::build() 只代表 WebSocket 已经初始化,不代表 SpacetimeDB 身份握手完成;如果过早调用 procedure,本地联调会表现为连接建立但请求长期没有回调,最终等到 idle timeout。

后续新增工作只随 WP-ST 新 table / reducer / procedure 或 row shape 稳定后按领域增量接入,不再把整个 WP-SC 包保持为进行中状态。新增 facade 时必须继续满足:

  1. 不手写 module_bindings 生成物。
  2. 不在 spacetime-client 内新增领域规则。
  3. procedure / reducer shape 稳定后再接 typed facade。
  4. 错误映射继续使用 SpacetimeClientError helper。
  5. mapper 测试或 facade 定向测试随新增场景补齐。

2.1 module_bindings 生成物约束

src/module_bindings 目录下的 Rust 文件统一视为 SpacetimeDB CLI 生成产物,后续维护必须遵守:

  1. 只允许通过仓库根目录 npm run spacetime:generate -- --rust-only 刷新,不允许手工修改。
  2. 不生成私有表绑定,不追加 --include-private;如后端需要读取私有表,应先在 api-server 或模块层补明确 contract,而不是让客户端 crate 直接依赖私有表结构。
  3. 不允许手工对该目录执行散装 rustfmt;若 SpacetimeDB CLI 已生成文件但自身 formatter 在 Windows 下失败,只能由 scripts/generate-spacetime-bindings.mjs 在短临时目录中分批 rustfmt 后同步。
  4. src/lib.rs 已通过 #[rustfmt::skip] pub mod module_bindings; 显式阻止 workspace 级 cargo fmt 继续递归格式化该目录。
  5. Windows 下 SpacetimeDB CLI 2.1.0 的生成后 formatter 可能因为一次性传入过多 Rust 文件路径而失败;仓库脚本会先输出到短临时目录,必要时接管分批格式化,再同步回本目录。

2.1.1 绑定缺文件恢复流程

若 mod.rs 已声明 *_table 模块,但目录内缺少对应 *_table.rs 文件,说明 Rust bindings 刷新不完整。不要手工补 generated code,统一在仓库根目录执行:

npm.cmd run spacetime:generate -- --rust-only

脚本内部会使用 --no-config:仓库根目录的 spacetime.json 同时配置了 TypeScript 与 Rust 两个生成目标,直接追加 --lang / --out-dir 会触发 SpacetimeDB CLI 的多目标参数冲突。

生成后用以下命令确认 mod.rs 声明的模块都有落盘文件:

$modFile = 'server-rs\crates\spacetime-client\src\module_bindings\mod.rs'
$dir = 'server-rs\crates\spacetime-client\src\module_bindings'
$mods = Select-String -Path $modFile -Pattern '^pub mod ([a-zA-Z0-9_]+);' |
  ForEach-Object { $_.Matches[0].Groups[1].Value }
$missing = @()
foreach ($m in $mods) {
  if (-not (Test-Path (Join-Path $dir ($m + '.rs')))) {
    $missing += $m
  }
}
if ($missing.Count -eq 0) { 'missing module files: 0' } else { $missing }

最后至少执行:

cargo check -p spacetime-client --manifest-path server-rs\Cargo.toml

3. 边界约束

  1. spacetime-client 只承接 SpacetimeDB 客户端访问适配,不承接具体业务模块的规则实现。
  2. 业务状态真相仍由 apps/spacetime-module 管理,业务编排由各模块 package 与 apps/api-server 承担。
  3. 不允许把 reducer、view、订阅调用细节重新散落到多个业务模块里各自实现。
  4. 新增 facade 必须等待对应 spacetime-module facade 稳定后再接,不提前假设 row shape。
  5. src/module_bindings/** 是生成产物,只能通过 SpacetimeDB CLI 生成流程刷新。