Filed unassigned and unlabelled for triage by the domain:spec seat, from the isolated contract review of PR #14868 (#14691; verdict on that card, "Out of scope observations"). Not that PR's change and not addressed there.
Observation (measured on origin/main 2263ca4d6 by the reviewer)
packages/rest/src/rest-server.ts:7540 registerCrudEndpoints mounts every CRUD route under dataPath = basePath + crud.dataPrefix — crud.dataPrefix is a live RestServerConfig key (liveness ledger crud_endpoints, live).- The discovery document advertises the same value:
rest-server.ts:3877 discovery.routes.data = realBase + dataPrefix.
packages/client/src/index.ts:6123-6303 hard-codes the data routes as /data/${object}… — the SDK never reads dataPrefix from discovery (or from anywhere).
So a deployment with a non-default crud.dataPrefix already has three surfaces that should agree — the mounts, the discovery document and the client SDK — with the SDK on the wrong side: it calls paths that are not mounted, while discovery tells any reader where the routes actually are. This is the Route & surface ownership §4 shape (one contract, N surfaces that must describe it identically) that PR #14868 cites for retiring crud.patterns — one key over, on a key that is live.
What a fix would decide (not decided here)
Either the SDK honours dataPrefix (reads it from discovery, or from a client option that defaults to /data), or the ledger's crud.dataPrefix row records that the SDK does not honour it and the key's contract is narrowed accordingly. The first keeps the key meaningful; the second is an enforce-or-remove question in the other direction. Both are contract decisions; the triage seat routes.
Dedupe
Open-issue scan (485 open issues at 06:09Z plus the 36 updated since): no open card names the SDK's fixed /data/ paths against dataPrefix. #14093 mentions dataPrefix only as context for an ActionSchema.method worked example — different subject. Closed neighbours not re-read.
Filed unassigned and unlabelled for triage by the
domain:specseat, from the isolated contract review of PR #14868 (#14691; verdict on that card, "Out of scope observations"). Not that PR's change and not addressed there.Observation (measured on
origin/main2263ca4d6by the reviewer)packages/rest/src/rest-server.ts:7540registerCrudEndpointsmounts every CRUD route underdataPath = basePath + crud.dataPrefix—crud.dataPrefixis a liveRestServerConfigkey (liveness ledgercrud_endpoints,live).rest-server.ts:3877discovery.routes.data = realBase + dataPrefix.packages/client/src/index.ts:6123-6303hard-codes the data routes as/data/${object}…— the SDK never readsdataPrefixfrom discovery (or from anywhere).So a deployment with a non-default
crud.dataPrefixalready has three surfaces that should agree — the mounts, the discovery document and the client SDK — with the SDK on the wrong side: it calls paths that are not mounted, while discovery tells any reader where the routes actually are. This is the Route & surface ownership §4 shape (one contract, N surfaces that must describe it identically) that PR #14868 cites for retiringcrud.patterns— one key over, on a key that is live.What a fix would decide (not decided here)
Either the SDK honours
dataPrefix(reads it from discovery, or from a client option that defaults to/data), or the ledger'scrud.dataPrefixrow records that the SDK does not honour it and the key's contract is narrowed accordingly. The first keeps the key meaningful; the second is an enforce-or-remove question in the other direction. Both are contract decisions; the triage seat routes.Dedupe
Open-issue scan (485 open issues at 06:09Z plus the 36 updated since): no open card names the SDK's fixed
/data/paths againstdataPrefix. #14093 mentionsdataPrefixonly as context for anActionSchema.methodworked example — different subject. Closed neighbours not re-read.