Summary
get_status reports a component and all its resources as healthy when its node_modules is absent from disk. Health reflects whether the component loaded successfully at some point in the past, not whether it could load now — so a component that has lost its dependencies looks fine until something reloads it.
Observed
On 5.1.x, a component whose node_modules had been destroyed days earlier (see #1973) reported:
('<component>.name', 'healthy')
('<component>.rest', 'healthy')
('<component>.graphqlSchema', 'healthy')
('<component>.jsResource', 'healthy')
('<component>.authentication', 'healthy')
…with availability: Available, and every other component healthy too. On disk the component directory held only source — no dependency tree. The worker had the modules resident in memory from a startup that predated the loss, so it kept serving.
The moment the process restarted, the same component failed to load:
ResourceLoadError: Failed to load resource module .../dist/resources/<module>.js
cause: Error: Cannot find module 'tweetnacl'
code: 'MODULE_NOT_FOUND'
Nothing in the status surface distinguished "running correctly" from "running on borrowed modules, will fail on next reload."
Why it matters
This is the failure mode that turns a recoverable install problem into a latent one. An operator has no signal, monitoring has no signal, and the breakage materializes during an unrelated restart — at which point the cause is days old and the correlation is easy to miss. It also means a rolling restart can take out a component that has looked healthy for days.
Suggested direction
Health for a component ought to reflect current loadability, not a cached load result. Options, roughly in increasing cost:
- Report a distinct state when a loaded component's on-disk dependencies are missing or don't match what was installed.
- Surface load-time module resolution failures as a component status, not only as log lines and unhandled rejections.
- Include a cheap dependency-presence check in the component health probe.
Any of these would have surfaced this within a health check instead of at the next restart.
Related: #1973 (the destructive install race), #1974 (why it never repaired itself).
🤖 Filed by Claude on behalf of @heskew
Summary
get_statusreports a component and all its resources ashealthywhen itsnode_modulesis absent from disk. Health reflects whether the component loaded successfully at some point in the past, not whether it could load now — so a component that has lost its dependencies looks fine until something reloads it.Observed
On 5.1.x, a component whose
node_moduleshad been destroyed days earlier (see #1973) reported:…with
availability: Available, and every other component healthy too. On disk the component directory held only source — no dependency tree. The worker had the modules resident in memory from a startup that predated the loss, so it kept serving.The moment the process restarted, the same component failed to load:
Nothing in the status surface distinguished "running correctly" from "running on borrowed modules, will fail on next reload."
Why it matters
This is the failure mode that turns a recoverable install problem into a latent one. An operator has no signal, monitoring has no signal, and the breakage materializes during an unrelated restart — at which point the cause is days old and the correlation is easy to miss. It also means a rolling restart can take out a component that has looked healthy for days.
Suggested direction
Health for a component ought to reflect current loadability, not a cached load result. Options, roughly in increasing cost:
Any of these would have surfaced this within a health check instead of at the next restart.
Related: #1973 (the destructive install race), #1974 (why it never repaired itself).
🤖 Filed by Claude on behalf of @heskew