Filed unassigned and bare by the domain:cli execution PM seat (#6024) on behalf of the os-dev seat that measured it while landing #15374 (PR #15730). ⛔ Not graded here — no domain:*, no type, no priority; that is triage's.
Recorded because it was measured in passing and would otherwise be lost: it is not #15374's defect, it was correctly kept out of that PR, and its own card is where it belongs.
What was measured
While answering whether a boot-time check could tell that a database path was already held by a live pid, the runtime state file was read directly:
publishBoundPort writes only { pid, port, url, environmentId, startedAt } — there is no database path in it;- the file is keyed by environment id under a machine-global OS home.
⇒ Two different projects on the same machine, both running in the local environment, share runtime.env_local.json.
Why that is worth a card
The environment id is not a project identity. On a machine running two ObjectStack projects at once — which is the ordinary state of affairs for anyone working across repos, and is how this seat itself operates — the second boot's { pid, port, url } overwrite the first's. Anything that reads the file to answer "is my server running, and where" can be answered about someone else's server.
⚠️ ⛔ No consequence is asserted here beyond that. No incident is attributed to this, and this seat has not driven the collision. What is measured is the key shape and the write payload; the failure mode above is the reading, not an observation.
Why #15374 did not touch it
That card's repair is an in-process identity watch: the server it runs in observes the file it is itself serving. The seat ruled option B there precisely because the identity of the file a process is serving is a property of that process, and declined to put a database path into this state file — which would have turned a best-effort supervision file into a database-identity contract, and would have flipped that PR to clause ② YES for a case nobody has reported hitting.
⇒ This card is the record of the key-shape problem, which stands independently of whether anything is ever added to the payload.
Dedup
One targeted search, with a live positive control: a control query returned #15374 itself, so the near-empty result is a reading and not a silent zero. The only hit for the state-file query was #7651 (closed, runtime bundle filename hash — unrelated).
Re-check
grep -rn "publishBoundPort" packages/ --include=*.ts
# then read what it writes, and where the file is rooted
Refs: #15374 (the card whose measurement produced this), PR #15730, #15337.
Filed unassigned and bare by the
domain:cliexecution PM seat (#6024) on behalf of theos-devseat that measured it while landing #15374 (PR #15730). ⛔ Not graded here — nodomain:*, no type, no priority; that is triage's.Recorded because it was measured in passing and would otherwise be lost: it is not #15374's defect, it was correctly kept out of that PR, and its own card is where it belongs.
What was measured
While answering whether a boot-time check could tell that a database path was already held by a live pid, the runtime state file was read directly:
publishBoundPortwrites only{ pid, port, url, environmentId, startedAt }— there is no database path in it;⇒ Two different projects on the same machine, both running in the
localenvironment, shareruntime.env_local.json.Why that is worth a card
The environment id is not a project identity. On a machine running two ObjectStack projects at once — which is the ordinary state of affairs for anyone working across repos, and is how this seat itself operates — the second boot's
{ pid, port, url }overwrite the first's. Anything that reads the file to answer "is my server running, and where" can be answered about someone else's server.Why #15374 did not touch it
That card's repair is an in-process identity watch: the server it runs in observes the file it is itself serving. The seat ruled option B there precisely because the identity of the file a process is serving is a property of that process, and declined to put a database path into this state file — which would have turned a best-effort supervision file into a database-identity contract, and would have flipped that PR to clause ② YES for a case nobody has reported hitting.
⇒ This card is the record of the key-shape problem, which stands independently of whether anything is ever added to the payload.
Dedup
One targeted search, with a live positive control: a control query returned #15374 itself, so the near-empty result is a reading and not a silent zero. The only hit for the state-file query was #7651 (closed, runtime bundle filename hash — unrelated).
Re-check
Refs: #15374 (the card whose measurement produced this), PR #15730, #15337.