Observation-class finding, no behaviour change requested. Found while adopting the artifact-pinned boot (#8368) on the ObjectOS EE image (cloud#1292). Filed unassigned.
What happens
With OS_ARTIFACT_URL set, serve resolves the reference, sets useArtifactFallback = true, and loads { mod: { default: {} } } — the objectstack.config.ts in the cwd is deliberately never executed. The boot diagnostics say so plainly:
Artifact (OS_ARTIFACT_URL): http://127.0.0.1:41541/hotcrm-2.2.2.json [remote, sha256 verified]
Booting from the artifact named by OS_ARTIFACT_URL (default host)...
But the ready banner a few lines later still reports:
Config: objectstack.config.ts
Mode: production
Driver: SqlDriver(better-sqlite3) → :memory:
printServerReady({ configFile: relativeConfig, … }) is passed relativeConfig unconditionally, and relativeConfig is derived from args.config at the top of run() — before the artifact branch is decided. So the row names a file that exists, was found, and was not read.
Why it is worth a line of code
The banner is the surface an operator uses to answer "what is this container actually running", and on this path that is the whole question the feature turns on — the two-axis model means the config in the image and the artifact in the env are different apps. A row that names the file that did not boot points the reader at the wrong one, and it does it on the same screen that just said the opposite. It cost a reading during the cloud-side adoption: the row is the first thing that looks authoritative, and the plugin table is what actually settles it.
The neighbouring precedent is #4801 (cloud#1020), where the banner's tenancy row disagreed with the runtime wiring and every later investigation paid for it.
Suggested shape
Report the artifact on this path instead of the config — the resolved display is already in hand (pinnedArtifact.display), already redacted for a pre-signed URL, and already printed by the diagnostic line above. Something like Artifact: <display> (OS_ARTIFACT_URL) in the Config: slot, or an added row with the Config: row omitted when useArtifactFallback is set.
Same for the plain artifact-fallback path (no config authored, dist/objectstack.json), where the row currently names a config file that does not exist.
Reproduce
objectstack build
OS_ARTIFACT_URL=file://$PWD/dist/objectstack.json objectstack serve objectstack.config.ts
# banner: Config: objectstack.config.ts ← never loaded
Verified at 8798cd2a60649f9a54d794a97da314d41be4ab7b.
Related: #8368, cloud#1292.
Observation-class finding, no behaviour change requested. Found while adopting the artifact-pinned boot (#8368) on the ObjectOS EE image (cloud#1292). Filed unassigned.
What happens
With
OS_ARTIFACT_URLset,serveresolves the reference, setsuseArtifactFallback = true, and loads{ mod: { default: {} } }— theobjectstack.config.tsin the cwd is deliberately never executed. The boot diagnostics say so plainly:But the ready banner a few lines later still reports:
printServerReady({ configFile: relativeConfig, … })is passedrelativeConfigunconditionally, andrelativeConfigis derived fromargs.configat the top ofrun()— before the artifact branch is decided. So the row names a file that exists, was found, and was not read.Why it is worth a line of code
The banner is the surface an operator uses to answer "what is this container actually running", and on this path that is the whole question the feature turns on — the two-axis model means the config in the image and the artifact in the env are different apps. A row that names the file that did not boot points the reader at the wrong one, and it does it on the same screen that just said the opposite. It cost a reading during the cloud-side adoption: the row is the first thing that looks authoritative, and the plugin table is what actually settles it.
The neighbouring precedent is #4801 (cloud#1020), where the banner's tenancy row disagreed with the runtime wiring and every later investigation paid for it.
Suggested shape
Report the artifact on this path instead of the config — the resolved
displayis already in hand (pinnedArtifact.display), already redacted for a pre-signed URL, and already printed by the diagnostic line above. Something likeArtifact: <display> (OS_ARTIFACT_URL)in theConfig:slot, or an added row with theConfig:row omitted whenuseArtifactFallbackis set.Same for the plain artifact-fallback path (no config authored,
dist/objectstack.json), where the row currently names a config file that does not exist.Reproduce
Verified at
8798cd2a60649f9a54d794a97da314d41be4ab7b.Related: #8368, cloud#1292.