Since #1806 (5.2.0-beta.2), deploy_component of an already-active component no longer flags restartRequired; change detection is delegated to the live file watchers. A redeploy swaps in a fresh component directory and recreates the watchers, so the post-deploy chokidar scan re-emits every file as a fresh add.
#1817 tracked the resulting stale-serving bug and #1820 fixed it — but only for jsResource (resources/jsResource.ts now tracks the files each scope has loaded; a re-add of a known file counts as a change). Two handlers still have the bare gate and silently ignore redeployed changes:
resources/loadEnv.ts:11 — if (entry.eventType !== 'add') scope.requestRestart(). A redeployed .env with changed values surfaces as add, so the new values are read only by the scanning thread; already-running workers keep the old env, get_status stays restartRequired: false, and tooling keyed off the flag skips the post-deploy restart. An extra manual restart is required before the new values load. Observed in the field on a replicated 5.2.0-beta.2 cluster; on 5.1.x this worked because every redeploy raised restart-required via the watcher change events, so the standard post-deploy restart picked env changes up.server/fastifyRoutes.ts:42 — same gate; a redeployed route file's re-add is ignored the same way. Not yet reported in the field — flagged from code inspection while confirming the loadEnv leg.
Not related to #1513 (that only blocks HARPER_CONFIG/HARPER_DEFAULT_CONFIG/HARPER_SET_CONFIG from component .env files).
Suggested fix: extend #1820's known-file re-add tracking to these handlers (for loadEnv, diffing the parsed env snapshot and calling requestRestart() on delta would also work and avoids false restarts on byte-identical redeploys). Two-phase deploy will need the same semantics — the in-flight two-phase work already extends #1806's restart-required behavior for new components.
Since #1806 (5.2.0-beta.2),
deploy_componentof an already-active component no longer flagsrestartRequired; change detection is delegated to the live file watchers. A redeploy swaps in a fresh component directory and recreates the watchers, so the post-deploy chokidar scan re-emits every file as a freshadd.#1817 tracked the resulting stale-serving bug and #1820 fixed it — but only for jsResource (
resources/jsResource.tsnow tracks the files each scope has loaded; a re-addof a known file counts as a change). Two handlers still have the bare gate and silently ignore redeployed changes:resources/loadEnv.ts:11—if (entry.eventType !== 'add') scope.requestRestart(). A redeployed.envwith changed values surfaces asadd, so the new values are read only by the scanning thread; already-running workers keep the old env,get_statusstaysrestartRequired: false, and tooling keyed off the flag skips the post-deploy restart. An extra manual restart is required before the new values load. Observed in the field on a replicated 5.2.0-beta.2 cluster; on 5.1.x this worked because every redeploy raised restart-required via the watcher change events, so the standard post-deploy restart picked env changes up.server/fastifyRoutes.ts:42— same gate; a redeployed route file's re-addis ignored the same way. Not yet reported in the field — flagged from code inspection while confirming the loadEnv leg.Not related to #1513 (that only blocks
HARPER_CONFIG/HARPER_DEFAULT_CONFIG/HARPER_SET_CONFIGfrom component.envfiles).Suggested fix: extend #1820's known-file re-
addtracking to these handlers (for loadEnv, diffing the parsed env snapshot and callingrequestRestart()on delta would also work and avoids false restarts on byte-identical redeploys). Two-phase deploy will need the same semantics — the in-flight two-phase work already extends #1806's restart-required behavior for new components.