v0.2.10
fix(provider): bind the named connections in register(), and finish the rollback
eon:<name> was created in boot(), so the container had a different surface
depending on whether the application was assembled to run or to be inspected —
and a boot that failed late left those factories behind, pointing at connections
it had just closed. The names come from the config, which register() can read:
nothing about eon:primary needs a socket to exist. Resolved before boot opens
one, it now says what is missing instead of answering undefined.
The rollback also destroys the connector's process-global handles. shutdown()
already says why closing the individual connections is not enough to let Node
exit; a failed boot skipped that step and the process hung.
fix(provider): give the migration name back on shutdown
MigrationRegistry.register refuses a duplicate name on purpose — two
providers claiming one means one migrates nothing while the run reports success.
Nothing ever removed a source, so a provider that stopped left its name taken
and its runner holding a connection it had already closed: a second boot in the
same process (a hot reload, a test that restarts the app) failed on 'already
registered', and the CLI would have driven a runner pointing at a dead pool.
Released on shutdown and on a failed boot, and only while it is still ours —
two applications can share a process, and the one stopping must not unregister
the survivor's runner because the name matches. A host without unregister
degrades silently rather than failing a shutdown over it.
fix(provider): roll back a boot that failed after the sockets opened
The connect step already rolled back. Everything after it did not: the container
bindings, the module singleton, the migration source. A failure there — a host
whose migration registry refused the source, a services module that would not
import — left the connections open, possibly the singleton published, and
#booted false, so the next attempt opened another set on top of the ones
nobody could reach.
The whole post-connection sequence is now one transaction with a single
rollback. It releases only what THIS attempt created: the module singleton goes
only while it is still the one we published, because two applications can share
a process and the survivor's connection has to stay.
fix(provider): register bindings in register(), and stop a flaky publication gate
register() was empty and every binding was made in boot(), after the sockets
were open. That is not where upstream puts them, and the reason is concrete: a
provider that booted before this one could not resolve eon.compiler at all,
and the container had a different surface depending on the mode the application
was assembled in.
The compiler is pure -- a call into the native compiler, no socket, no database
-- so nothing about it needed to wait for boot. The connection tokens move too,
so the surface no longer depends on the mode; what they RESOLVE to still needs
boot to have opened something, and reading one too early now says what to do
instead of answering undefined and failing several frames away.
Separately: the one test that pulls the whole testing graph through a dynamic
import gets a longer timeout. Under coverage every module in that graph is
instrumented on the way in, which on a loaded machine crossed a 5-second default
the assertion itself is nowhere near -- and made the publication gate fail at
random on a test that has nothing slow about it.
Changes since v0.2.9.