v0.2.17
Isolate the scheduler-autoload cases without rebuilding the module graph
The negative cases needed a registry that had never seen the fixture, and the
first draft got one with vi.resetModules() per case. That invalidates the
worker's whole module cache, so every later dynamic import came back cold —
and a 5-second test timeout became a coin flip, for this file and for its
neighbours. One run in three was red, on tests that passed alone.
Each case now points at its own fixture, and asks whether ITS task is present
rather than whether the registry is empty. No reset, no ordering dependence,
and the assertion is the more precise one anyway: what is under test is
whether the autoload imported that file. Four consecutive full runs green.
Release 0.2.17
0.2.16 went to npm at 08:26 UTC, and three commits landed after it under the
same version: the schedule:list diagnostic, app.rcFile, and terminate() taking
the HTTP server down with it. None of them is in what was published.
The v0.2.16 tag is back on 4eb8bf3, the commit that WAS published, and this
version carries the rest.
Assert the scheduler fired, not how many times the clock allowed
The window is 65 seconds because the grammar is five fields: once a minute is
as often as a task can run, so that is the shortest span guaranteed to cross a
boundary. A run starting at :56 crosses two and fires twice — the scheduler
working — and asserting exactly one failed on the clock rather than on the
behaviour.
Take the HTTP server down with the application
terminate() shut the providers down and called process.exit(0). The socket,
the error boundary and the service locators belong to the Ignitor, so none of
them was released — and the exit could win the race against a drain another
path had already begun, which is exactly what the signal wiring in this file's
own example set up.
It follows upstream now: terminating hooks, run in reverse, then the providers,
and no exit. Whoever opens the socket registers the close, so the Ignitor does;
graceful shutdown terminates the application rather than stopping the Ignitor,
so there is one authority however the shutdown was triggered. terminate() and
shutdown() are both re-entrant, because two signals arriving together must not
close a pool twice.
Say why no scheduled task was found
Discovery reads the IoC service registry, so a class nothing imported is not
there to find. A @schedule in app/modules/** therefore depends on the module
auto-loader having imported the file, and that has two conditions the
folder-structure guide does not lead anyone to expect: reamrc.modules.path
must be set at all, and modules.autoload must name the file — it defaults to
routes and events, so billing/scheduler.ts is skipped. Either way the symptom
was the same unexplained line.
schedule:list now names whichever condition is unmet, reading it from
app.rcFile — which the application now keeps whole, as upstream does, instead
of only the directories key.
The scheduling doc claimed app/modules/** was loaded unconditionally. Both
locales now state the two conditions and point at a preload, which is explicit
and does not depend on where the file sits.
Changes since v0.2.16.
