While fixing #10993 (/health and HttpDispatcher.getDiscoveryInfo() both hardcoded version: '1.0.0'), the same defect was measured in a third producer, in a different package:
packages/metadata-protocol/src/protocol.ts:5095
return {
version: '1.0',
name,
...
getDiscovery() (served over REST by @objectstack/rest, packages/rest/src/rest-server.ts:3196) is the SECOND DiscoverySchema-conforming producer alongside HttpDispatcher.getDiscoveryInfo() (see protocol.zod.ts's own doc comment: "DiscoverySchema is authoritative for PRODUCERS... each producer's live shape must satisfy it"). It fills the identical version: z.string() "System Identity" field with its own unrelated literal — '1.0', not even '1.0.0' — which is itself evidence neither literal was ever a meaningful contract value: two producers of the "same" field disagree with each other and both are constant.
Out of scope for #10993 on purpose: that issue's census was packages/runtime/src/http-dispatcher.ts (confirmed: two sites, both fixed there), and this is a different package (@objectstack/metadata-protocol) with its own producer function — not "the same file," so the bounded in-place-fix exemption doesn't reach it.
Suggested shape, following #10993's fix and triage ruling (derive from an injected build stamp / env var, package version as fallback, never a literal — OS_RUNTIME_VERSION, the existing convention already read by packages/cloud-connection/src/cloud-connection-plugin.ts): packages/runtime/src/runtime-version.ts's resolveRuntimeVersion() is package-local to @objectstack/runtime and metadata-protocol cannot import it (wrong dependency direction — runtime depends on metadata-protocol, not the reverse), so this needs either its own small resolver reading @objectstack/metadata-protocol's own package.json, or a shared helper hoisted somewhere both packages can reach (e.g. @objectstack/types or @objectstack/core, both already dependencies of metadata-protocol) — worth deciding at triage rather than duplicating the resolver blind.
Evidence this is real artifact-identity semantics, not a separately-contracted protocol/API version: the SDK's connect() (packages/client/src/index.ts:567) logs data.version right alongside apiName and services under "Connected to ObjectStack server" — i.e. it is read as "what server is this," the same purpose /health's version serves, not a wire-protocol version (the informal "protocol N" numbering used in code comments near GetDiscoveryResponseSchema is a documentation-only convention with no schema field of its own).
While fixing #10993 (
/healthandHttpDispatcher.getDiscoveryInfo()both hardcodedversion: '1.0.0'), the same defect was measured in a third producer, in a different package:getDiscovery()(served over REST by@objectstack/rest,packages/rest/src/rest-server.ts:3196) is the SECONDDiscoverySchema-conforming producer alongsideHttpDispatcher.getDiscoveryInfo()(seeprotocol.zod.ts's own doc comment: "DiscoverySchemais authoritative for PRODUCERS... each producer's live shape must satisfy it"). It fills the identicalversion: z.string()"System Identity" field with its own unrelated literal —'1.0', not even'1.0.0'— which is itself evidence neither literal was ever a meaningful contract value: two producers of the "same" field disagree with each other and both are constant.Out of scope for #10993 on purpose: that issue's census was
packages/runtime/src/http-dispatcher.ts(confirmed: two sites, both fixed there), and this is a different package (@objectstack/metadata-protocol) with its own producer function — not "the same file," so the bounded in-place-fix exemption doesn't reach it.Suggested shape, following #10993's fix and triage ruling (derive from an injected build stamp / env var, package version as fallback, never a literal —
OS_RUNTIME_VERSION, the existing convention already read bypackages/cloud-connection/src/cloud-connection-plugin.ts):packages/runtime/src/runtime-version.ts'sresolveRuntimeVersion()is package-local to@objectstack/runtimeandmetadata-protocolcannot import it (wrong dependency direction —runtimedepends onmetadata-protocol, not the reverse), so this needs either its own small resolver reading@objectstack/metadata-protocol's ownpackage.json, or a shared helper hoisted somewhere both packages can reach (e.g.@objectstack/typesor@objectstack/core, both already dependencies ofmetadata-protocol) — worth deciding at triage rather than duplicating the resolver blind.Evidence this is real artifact-identity semantics, not a separately-contracted protocol/API version: the SDK's
connect()(packages/client/src/index.ts:567) logsdata.versionright alongsideapiNameandservicesunder "Connected to ObjectStack server" — i.e. it is read as "what server is this," the same purpose/health's version serves, not a wire-protocol version (the informal "protocol N" numbering used in code comments nearGetDiscoveryResponseSchemais a documentation-only convention with no schema field of its own).