You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit d37ac1c
Browse filesBrowse the repository at this point in the historyBrowse files
fix(service-job): destroy the cron adapter on kernel eviction so scheduled flows re-bind (#8362) (#8462)
DbJobAdapter.destroy() only destroyed `inner`, never the CronJobAdapter it was
constructed with. Kernel eviction is routine in the cloud runtime, so every
evicted kernel left its croner timers running and holding their PROCESS-GLOBAL
croner names forever; the rebuilt kernel then failed to re-bind that flow
permanently, with one unwatched WARN as the only signal.
- DbJobAdapter.destroy() destroys the cron adapter too (the single-point cause),
reporting a failure to do so at error level (persisted vs runtime state
disagreeing, invisible everywhere else).
- JobServicePlugin releases the cron adapter it owns on the `adapter: 'cron'`
path, where nothing else would.
- CronJobAdapter scopes its croner registry key to the adapter INSTANCE, which
also fixes cross-environment collisions in one container with no eviction
involved. Per-instance rather than per-environment on purpose: a rebuilt
kernel reuses the environment id, which is the collision itself.
- Claiming a registry name a foreign job still holds now STOPS that job and
replaces it, rather than warning and giving up. Stopping matters: a leaked
croner job is a live timer closed over a shut-down kernel, so taking the name
while leaving it running would trade a silent death for a zombie double-write.
- Both triggers report a failed bind at error with consequence and remedy.
Claude-Session: https://claude.ai/code/session_01ARidKDYSCD56LaygrvDPnk
Co-authored-by: Claude <noreply@anthropic.com>
0 commit comments