The job-reservation reference specs (src/reference/specs/autopopulate.md, job-metadata.md) say nothing about signal handling, yet datajoint-python has specific, load-bearing SIGTERM behavior during populate() that operators of distributed workers depend on:
populate() installs a SIGTERM handler for the duration of each cycle; a SIGTERM mid-make() raises SystemExit, which escapes except Exception (so suppress_errors=True does not swallow it), cancels the open transaction, and records the job as error with a %SIGTERM% message.%SIGTERM% is in the permanent-error patterns, so the worker's next cycle deletes the matching error row and the key re-queues — the interrupted work is redone, not lost.- By contrast, a signal with no installed handler (default disposition: terminate) kills the process outright: no transaction cancel, no
jobs.error() row — the job stays reserved until reclaimed via refresh(orphan_timeout=...).
None of this is derivable from the current specs, and it matters for anyone designing worker lifecycle management, container orchestration (SIGTERM on pod eviction), or graceful-drain schemes on top of DataJoint. Suggested home: a "Signals and interruption" section in autopopulate.md covering the handler's scope, the transaction/job-state consequences, the redo-vs-lost distinction, and the orphaned-job reclaim path. Verify the exact mechanics against autopopulate.py/the worker code at writing time rather than from this summary.
The job-reservation reference specs (
src/reference/specs/autopopulate.md,job-metadata.md) say nothing about signal handling, yetdatajoint-pythonhas specific, load-bearing SIGTERM behavior duringpopulate()that operators of distributed workers depend on:populate()installs a SIGTERM handler for the duration of each cycle; a SIGTERM mid-make()raisesSystemExit, which escapesexcept Exception(sosuppress_errors=Truedoes not swallow it), cancels the open transaction, and records the job aserrorwith a%SIGTERM%message.%SIGTERM%is in the permanent-error patterns, so the worker's next cycle deletes the matching error row and the key re-queues — the interrupted work is redone, not lost.jobs.error()row — the job staysreserveduntil reclaimed viarefresh(orphan_timeout=...).None of this is derivable from the current specs, and it matters for anyone designing worker lifecycle management, container orchestration (SIGTERM on pod eviction), or graceful-drain schemes on top of DataJoint. Suggested home: a "Signals and interruption" section in
autopopulate.mdcovering the handler's scope, the transaction/job-state consequences, the redo-vs-lost distinction, and the orphaned-job reclaim path. Verify the exact mechanics againstautopopulate.py/the worker code at writing time rather than from this summary.