Found while clearing the showcase's boot warnings for #4774. Not caused by that change — it reproduces identically before and after — so it is filed rather than fixed there.
What happens
Every examples/app-showcase boot logs:
WARN StorageServicePlugin: storage adapter swapped (LocalStorageAdapter → LocalStorageAdapter).
Existing files were NOT migrated and may be unreachable through the new adapter.
After #4774 lands this is one of only two warnings left in the showcase's boot diagnostics, so it is now a visible share of the reference app's noise.
Why it is wrong
The message is the loud branch of a two-branch guard in packages/services/service-storage/src/storage-service-plugin.ts (~225). The quiet branch exists for exactly this case:
ctx.logger.info(
`StorageServicePlugin: storage adapter replaced (${prevName} → ${nextName}) — `
+ 'same backing store, existing files unaffected.',
);
return;…but the boot takes the warn branch even though prevName === nextName === 'LocalStorageAdapter', i.e. the "same backing store" the info branch describes. Whatever the sameness predicate is keying on, it is not answering "did the backing store change".
Why it is worth fixing rather than tolerating
The warning claims potential data loss ("existing files … may be unreachable"). On a deployment where an adapter genuinely was swapped that is exactly the right thing to say — which is why it must not also fire when nothing was swapped. A data-loss warning that appears on every clean boot of the reference app is the fastest way to train operators to skim the one that matters, which is the failure mode AGENTS.md's "Degradation log levels" section is written against.
It is also a declared ≠ real report in the sense of Prime Directive #10: the log asserts a state transition the runtime did not perform.
Repro
pnpm --filter @objectstack/example-showcase exec objectstack dev --fresh -p 39774 --log-level warn
Observed on main @ 6bc93dc. Also present in the #4774 baseline capture (8-warning boot) and in the fixed one (2-warning boot).
Suggested direction
Compare what actually determines reachability — adapter class and its resolved backing location (local root / bucket + prefix) — and take the info branch when they are unchanged. A second, independent question worth a look while in there: why the adapter is constructed twice on a single boot at all.
Filed unassigned per Prime Directive #10.
Found while clearing the showcase's boot warnings for #4774. Not caused by that change — it reproduces identically before and after — so it is filed rather than fixed there.
What happens
Every
examples/app-showcaseboot logs:After #4774 lands this is one of only two warnings left in the showcase's boot diagnostics, so it is now a visible share of the reference app's noise.
Why it is wrong
The message is the loud branch of a two-branch guard in
packages/services/service-storage/src/storage-service-plugin.ts(~225). The quiet branch exists for exactly this case:…but the boot takes the
warnbranch even thoughprevName === nextName === 'LocalStorageAdapter', i.e. the "same backing store" the info branch describes. Whatever the sameness predicate is keying on, it is not answering "did the backing store change".Why it is worth fixing rather than tolerating
The warning claims potential data loss ("existing files … may be unreachable"). On a deployment where an adapter genuinely was swapped that is exactly the right thing to say — which is why it must not also fire when nothing was swapped. A data-loss warning that appears on every clean boot of the reference app is the fastest way to train operators to skim the one that matters, which is the failure mode AGENTS.md's "Degradation log levels" section is written against.
It is also a
declared ≠ realreport in the sense of Prime Directive #10: the log asserts a state transition the runtime did not perform.Repro
pnpm --filter @objectstack/example-showcase exec objectstack dev --fresh -p 39774 --log-level warnObserved on
main@ 6bc93dc. Also present in the #4774 baseline capture (8-warning boot) and in the fixed one (2-warning boot).Suggested direction
Compare what actually determines reachability — adapter class and its resolved backing location (local root / bucket + prefix) — and take the
infobranch when they are unchanged. A second, independent question worth a look while in there: why the adapter is constructed twice on a single boot at all.Filed unassigned per Prime Directive #10.