- 上行(作者、Bearer + 发布灰度,与发行包族逐条对齐):`PUT /versions/{id}/project-bundle`(整包一次上传,≤ 200 MiB)、`GET …/project-bundle/upload-state`、`PUT …/project-bundle/chunk`(`x-genarrative-upload-offset`,分片上限同发行包)、`POST …/project-bundle/complete`、`POST …/project-bundle/reset`;载体一律 `application/octet-stream`,分片边界与偏移语义只有一套
- 对象键:新增 `game_distribution_project_bundle_object_key(game_id, version_id)` = `…/{version_id}.project.zip`;发行包 helper **未改**(仍是 `.zip`)→ 同一(作品, 版本)的两份资产互不覆盖、也不会串用读取缓存
- 阶段门:新增**唯一**共享函数 `ensure_project_bundle_uploadable`,5 条上行路由全部调用、无重复实现。判定顺序:① 已确认(`project_bundle_bytes > 0`)→ 409 `PROJECT_BUNDLE_ALREADY_EXISTS`(必须先判:确认工程包不驱动版本状态机,已确认的版本可能仍停在 `awaiting_upload`);② `status` ∉ {`awaiting_upload`, `upload_failed`} → 409 `PROJECT_BUNDLE_UPLOAD_NOT_ALLOWED`(与模块事务同口径)
- `complete`:回读整包 → 与 HEAD 权威长度比对 → `validate_project_bundle_zip`(失败删半包对象 + 记上传失败 + 422 `PROJECT_BUNDLE_VALIDATION_FAILED`)→ `confirm_game_distribution_project_bundle`;幂等键与摘要口径照抄发行包 complete
- 下行优先:`fork_source_target` 选定资产 = 有工程包时 `Project`(优先)否则 `Package`;「字节数 > 0 **且**摘要非空」才算有工程包,半写行回落 `package`(失败关闭)。元数据 `source` / `sha256` / `bytes` / `downloadPath` 随所选资产;新增 `GET /games/{id}/fork-source/project`(同两层中间件、无 Query 提取器;没有工程包时 409 `FORK_SOURCE_NOT_AVAILABLE`,**绝不静默回落成品包**),响应头与成品包同形(文件名 `{gameId}-{versionId}-project.zip`)
- 缓存键加资产维度:`release_package_bytes` 泛化为 `release_asset_bytes(state, object_key, max_bytes)`(缓存键即对象键),发行包侧退化为薄封装——键字符串、上限、`Bytes` 值类型与 4 条 / 256 MiB 预算逐字节不变,既有缓存测试继续通过
- 顺着同一「不复制第二套」原则抽出/参数化的共享件:`fork_source_bundle_response`(两份资产共用响应构造)、`package_upload_offset(headers, asset)`、`require_octet_stream_content_type(headers, asset)`(按资产给错误文案,发行包文案不变)
- 补上块 A 遗漏的两处客户端登记(否则下行字段读不到):`spacetime_client` 对 `GameDistributionConfirmProjectBundleRecordInput` 的 re-export,以及 `GameDistributionForkSourceRecord` 新增 `project_bundle_sha256` / `project_bundle_bytes` 与对应映射
- 测试 6 条:5 条上行 + 1 条下行共 6 条路由未带 Bearer → 401(逐条);`ensure_project_bundle_uploadable` 全状态(含「已确认优先于阶段」)+ 7 档拒绝;`fork_source_target` 6 种资产组合(工程包优先 / 回落成品包 / 两种半写行 / 只有工程包 / 两份都缺 → 409);两个对象键互不相等 + `ReleasePackageCache` 双资产不串味;上限镜像(`MAX_PROJECT_BUNDLE_BYTES == MAX_PACKAGE_BYTES == shared_contracts::GAME_DISTRIBUTION_MAX_PACKAGE_BYTES`、分片放行量 > 分片大小);校验失败 422 映射
- 门禁:`cargo check --all-targets` 0;`cargo test -p api-server game_distribution` **60 passed**(基线 54;既有发行包族用例全绿 → 抽取共享件未改发行包行为);DTO parity 42 组 OK;`check:encoding` 5301 files OK;`git diff --check` 0;`cargo fmt --all -- --check` 0
spacetime-client 共享 package 说明
日期:2026-05-01
1. package 职责
spacetime-client 是 SpacetimeDB 客户端适配 package,后续负责:
- 生成 bindings 后的客户端访问封装
- Axum 与各模块对 reducer、view、订阅的调用适配
- 身份透传、连接配置与基础错误处理适配
在 DDD 重构中,本 package 只承接 WP-SC Spacetime Client:
- 把 SpacetimeDB 生成绑定转换成
api-server可消费的 typed facade。 - 把 row snapshot / procedure result 转换成 BFF record。
- 统一 SDK 调用错误、业务 procedure 错误、缺失快照错误和超时错误。
- 不承载领域规则,不直接定义 table / reducer / procedure,不替代
spacetime-module。
当前约束见 ../../../docs/【后端架构】server-rs与SpacetimeDB数据契约-2026-05-15.md。
2. 当前完成口径
当前目录已不再只是占位。WP-SC Spacetime Client 在当前稳定 SpacetimeDB facade 范围内已经完成收尾:
- 通过
npm run spacetime:generate -- --rust-only生成并纳管公开 Rust bindings。 DbConnection调用连接池、单一缓存读连接、握手等待、超时和断线清理已封装在SpacetimeClient内部;调用池不订阅 read model,HTTP 角色额外使用一条共享连接保存订阅行缓存。- 已稳定的 assets、auth、AI task、Big Fish、Custom World、Puzzle、Runtime/Profile/Save、Story session、combat、inventory、NPC facade 均通过 typed 方法对外暴露。
- 生成绑定到 BFF record / module record 的 row snapshot mapper 已集中在
mapper.rs。 - SDK 调用错误、reducer 业务错误、procedure 业务错误、缺快照错误和本地输入校验错误已统一收口到
SpacetimeClientErrorhelper。 - Story runtime projection source 已复用 runtime inventory typed facade,读取投影不再只依赖 runtime snapshot 中的历史背包 JSON 副本。
- 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 时必须继续满足:
- 不手写
module_bindings生成物。 - 不在
spacetime-client内新增领域规则。 - procedure / reducer shape 稳定后再接 typed facade。
- 错误映射继续使用
SpacetimeClientErrorhelper。 - mapper 测试或 facade 定向测试随新增场景补齐。
2.1 module_bindings 生成物约束
src/module_bindings 目录下的 Rust 文件统一视为 SpacetimeDB CLI 生成产物,后续维护必须遵守:
- 只允许通过仓库根目录
npm run spacetime:generate -- --rust-only刷新,不允许手工修改。 - 不生成私有表绑定,不追加
--include-private;如后端需要读取私有表,应先在api-server或模块层补明确 contract,而不是让客户端 crate 直接依赖私有表结构。 - 不允许手工对该目录执行散装
rustfmt;若 SpacetimeDB CLI 已生成文件但自身 formatter 在 Windows 下失败,只能由scripts/generate-spacetime-bindings.mjs在短临时目录中分批rustfmt后同步。 src/lib.rs已通过#[rustfmt::skip] pub mod module_bindings;显式阻止 workspace 级cargo fmt继续递归格式化该目录。- 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. 边界约束
spacetime-client只承接 SpacetimeDB 客户端访问适配,不承接具体业务模块的规则实现。- 业务状态真相仍由
apps/spacetime-module管理,业务编排由各模块 package 与apps/api-server承担。 - 不允许把 reducer、view、订阅调用细节重新散落到多个业务模块里各自实现。
- 新增 facade 必须等待对应
spacetime-modulefacade 稳定后再接,不提前假设 row shape。 src/module_bindings/**是生成产物,只能通过 SpacetimeDB CLI 生成流程刷新。