fix(context): a restart reproduces a cold start (release 26.09.04) - #164
Merged
Conversation
26.09.03 made stop() release the singletons it built, but the REGISTRATIONS the previous start() created were left in place, so the next start() layered a second pipeline on top of them instead of rebuilding. Two things went wrong, both silent: - a @bean reachable under several keys — its concrete class and the protocol it satisfies — stopped being one object. The first start aliased those keys to a single instance; the restart resolved each key independently and called the factory once per key, so get_bean(Protocol) and get_bean(Concrete) returned different singletons. - the registration set drifted, because the @conditional_on_* passes re-evaluated against a registry that already held the previous run's output rather than against the user's own definitions. start() now records exactly which registrations its pipeline added and drops them at the next start, so the registry a restart begins from is the one a cold start begins from. Completes the lifecycle trilogy of 26.09.02 (idempotent start), 26.09.03 (stop releases what it destroyed) and this release, all found by one service sharing a module-level application across test modules. Release 26.09.04.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Completes the lifecycle trilogy of #162 and #163.
26.09.03madestop()release the singletons it built, but the registrations the previousstart()created were left in place, so the nextstart()layered a second pipeline on top of them instead of rebuilding.Two things went wrong, both silent:
@beanreachable under several keys — its concrete class and the protocol it satisfies — stopped being one object. The first start aliased those keys to a single instance; the restart resolved each key independently and called the factory once per key, soget_bean(Protocol)andget_bean(Concrete)returned different singletons.@conditional_on_*passes re-evaluated against a registry that already held the previous run's output rather than against the user's own definitions.start()now records exactly which registrations its pipeline added and drops them at the next start, so the registry a restart begins from is the one a cold start begins from.Two tests pin it: a bean published under an interface stays one instance across a restart, and the registration set after a restart is identical to the set after the cold start.
pytest tests/mypy src/pyfly --strictruff check/format --check