Filing unassigned — recorded as an out-of-scope finding from #7848 / PR #7982 (Prime Directive #10), not started.
What is true after #7848
HttpTestAdapter (packages/core/src/qa/http-adapter.ts) no longer hard-codes /api/data. Its record action types (create_record, read_record, update_record, delete_record, query_records) build their URLs from the two schemas RestServer itself resolves from:
RestApiConfigSchema → apiPath ?? ${basePath}/${version} (the expression RestServer.getApiBasePath() evaluates)CrudEndpointsConfigSchema.dataPrefix
which is what closed the 404s. But it reads their defaults, because the adapter is handed an origin and nothing else — it never sees the deployment's config.
The gap
Both pieces are configurable, and a deployment that moves the mount is invisible to the adapter:
| config | server serves | adapter asks | result |
|---|
| stock | /api/v1/data/:object | /api/v1/data/:object | ✅ |
api.apiPath: '/api/2026-01' | /api/2026-01/data/:object | /api/v1/data/:object | ❌ 404 |
crud.dataPrefix: '/objects' | /api/v1/objects/:object | /api/v1/data/:object | ❌ 404 |
The failure reads exactly like the one #7848 fixed — a 404 that looks like the suite author's own URL mistake rather than a platform limitation. Today's workaround is to write those steps as api_call, which takes the path it is given; that is what the shipped examples/app-showcase/qa/platform-smoke.test.json does throughout.
The shape a fix probably takes
@objectstack/client already answers this question and is the precedent worth copying rather than re-inventing (packages/client/src/index.ts, getRoute): prefer the server's own routes.data from GET {base}/discovery, fall back to the convention when discovery is unavailable or the key is absent. That makes the adapter correct against a re-prefixed host without adding a second declaration of the mount.
Two things to decide rather than assume:
- Bootstrap. Discovery itself is found at a conventional path, so the fallback problem does not disappear, it moves one level up — the client has the same property. Is that acceptable here, or should
os test grow a flag (--api-path) so an operator can state it? - Cost and failure mode. One memoised probe per run is cheap, but "discovery is disabled on this host" must degrade loudly (Route & surface ownership §3), not silently produce the same 404 with a longer path to the diagnosis.
Not urgent, and why
Every fixture boot in the repo — showcase, CRM, the platform-checklist runs — is stock, so nothing in-repo hits this. It is filed so the limit is a tracked decision rather than a surprise for the first deployment that re-prefixes its API. Recorded in docs/qa/platform-checklist/areas/cli.json (cli.qa-suite-execution, fixtures.knownGaps) and in content/docs/deployment/cli.mdx, so it is stated where an author would look.
Generated by Claude Code
Filing unassigned — recorded as an out-of-scope finding from #7848 / PR #7982 (Prime Directive #10), not started.
What is true after #7848
HttpTestAdapter(packages/core/src/qa/http-adapter.ts) no longer hard-codes/api/data. Its record action types (create_record,read_record,update_record,delete_record,query_records) build their URLs from the two schemasRestServeritself resolves from:RestApiConfigSchema→apiPath ?? ${basePath}/${version}(the expressionRestServer.getApiBasePath()evaluates)CrudEndpointsConfigSchema.dataPrefixwhich is what closed the 404s. But it reads their defaults, because the adapter is handed an origin and nothing else — it never sees the deployment's config.
The gap
Both pieces are configurable, and a deployment that moves the mount is invisible to the adapter:
/api/v1/data/:object/api/v1/data/:objectapi.apiPath: '/api/2026-01'/api/2026-01/data/:object/api/v1/data/:objectcrud.dataPrefix: '/objects'/api/v1/objects/:object/api/v1/data/:objectThe failure reads exactly like the one #7848 fixed — a 404 that looks like the suite author's own URL mistake rather than a platform limitation. Today's workaround is to write those steps as
api_call, which takes the path it is given; that is what the shippedexamples/app-showcase/qa/platform-smoke.test.jsondoes throughout.The shape a fix probably takes
@objectstack/clientalready answers this question and is the precedent worth copying rather than re-inventing (packages/client/src/index.ts,getRoute): prefer the server's ownroutes.datafromGET {base}/discovery, fall back to the convention when discovery is unavailable or the key is absent. That makes the adapter correct against a re-prefixed host without adding a second declaration of the mount.Two things to decide rather than assume:
os testgrow a flag (--api-path) so an operator can state it?Not urgent, and why
Every fixture boot in the repo — showcase, CRM, the platform-checklist runs — is stock, so nothing in-repo hits this. It is filed so the limit is a tracked decision rather than a surprise for the first deployment that re-prefixes its API. Recorded in
docs/qa/platform-checklist/areas/cli.json(cli.qa-suite-execution,fixtures.knownGaps) and incontent/docs/deployment/cli.mdx, so it is stated where an author would look.Generated by Claude Code