Repository navigation
feat: add manage_lifespan flag to setup_di - #46
Merged
Merged
Conversation
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
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.
Closes #45
setup_di(app, container)takes a keyword-onlymanage_lifespan: bool = True, with the same name and default as modern-di-fastmcp. The default changes nothing.With
manage_lifespan=Falsethe four worker signal handlers skipopen()andclose_sync(). Everything else still runs: theworker_process_inithandler still binds the container to a spawn child's app, each handler still acts only for the app that owns the container, and@injectstill builds, opens and closes a child container per task call. The user owns the root container, for example withasync with container:around running the apps.The check sits in two small helpers,
_open_forand_close_for, so the binding call in the process-init handler runs before the flag is consulted.README: the flag is in the API table, and a new "Sharing a container" section shows the user owning the root. It also says that a prefork child inherits the open container and nothing closes it there with the flag off, so the user closes it from their own
worker_process_shutdownhandler if the child's APP finalizers must run. CONTEXT.md: the root container entry notes that the flag hands opening and closing to the user.Tests, each written to fail before the change:
async with, the APP finalizer runs once, at the user's exitExisting tests for the default are unchanged.