feat: reserved invocation_settings envelope field on generated /invoke - #72
Closed
CyMule wants to merge 1 commit into
Closed
feat: reserved invocation_settings envelope field on generated /invoke#72CyMule wants to merge 1 commit into
CyMule wants to merge 1 commit into
Conversation
Every wrap_in_fastapi-generated /invoke now accepts an optional invocation_settings object as a reserved envelope field. It is kept out of the function's /schema (no namespace collision with data inputs) and delivered either as a kwarg when the wrapped function declares an invocation_settings parameter, or via the get_invocation_settings() ContextVar accessor otherwise (context propagated across the executor thread). The ContextVar is set even on the kwarg path so helper code deep in a plugin's call stack can always use the accessor. GET /capabilities advertises support so callers (e.g. the ETL controller) can gate injection without schema sniffing. The signature check for the kwarg path is hoisted to wrap time; requests pay a boolean, not reflection. This lets one standing plugin process serve work items with differing node settings (warm pools, worker fleets, per-invoke reconfiguration) instead of freezing settings from a boot-time file. 75 tests passed (5 new in test/test_invocation_settings.py).
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.
What
Every
wrap_in_fastapi-generated/invokegains a reserved, optionalinvocation_settingsenvelope field:/schema— settings can never collide with data inputs in the schema namespace.invocation_settings, or via the newget_invocation_settings()ContextVar accessor otherwise (context propagated across the executor thread; set on both paths so helpers deep in a plugin's call stack can always use the accessor).GET /capabilitiesadvertises support, so callers (the ETL controller) gate injection on capability instead of schema sniffing.inspect.signature.Why
Today every plugin freezes its settings from a boot-time mounted file, which pins plugin processes to a single job configuration. That coupling is what forces per-job pod provisioning and per-DAG-template warm pools. A reserved envelope field makes one standing plugin process able to serve work items with differing node settings — the plugin-side prerequisite ("plugins take settings from /invoke — table stakes") for pooled/fleet execution, and immediately useful for per-invoke reconfiguration in the existing architecture.
Companion PRs completing the chain (each independently mergeable; this one first):
feat(etl-job-api): deliver invocation_settings with claimed workfeat(controller): forward claim-delivered invocation_settings to plugin /invokeTesting
75 passed (5 new in
test/test_invocation_settings.py): kwarg delivery, accessor delivery, executor-thread propagation, schema exclusion, capabilities endpoint.