feat(worker-bottomup): thread phase_settings through bottom-up gather path (Phase 2 #33)#278
Merged
charlie83Gs merged 4 commits intomainfrom Apr 20, 2026
Merged
Conversation
…s (Phase 2 #31) ``DecompositionPipeline`` now accepts an optional ``phase_settings: Mapping[str, Any] | None`` kwarg at construction and exposes the value through a read-only ``phase_settings`` property. Workers construct the dict from ``graph_config.for_phase("fact_decomposition")`` and pass it in so the pipeline's view of per-graph overrides is pinned for the duration of the task. Stored as a defensive-copied ``MappingProxyType`` — callers can't leak mutations into pipeline state after construction, and providers can't mutate the shared dict back into the graph config. This closes Phase 2 plumbing: workers in Phase 2 threading PRs (#32/#33) now have a landing spot for per-graph phase settings. The concrete ``FactDecompositionProvider`` consumes these knobs in Phase 4. 4 new tests cover: default-empty view, key round-trip, defensive copy, read-only enforcement. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…onPipeline (Phase 2 #32) Adds ``kt_hatchet.composition.resolve_phase_settings(state, graph_id, phase)`` — the shared helper that translates a running graph's ``GraphConfig`` into the ``phase_settings`` dict ``DecompositionPipeline`` now accepts (#31 / #276). Fails fast on resolver error: a graph opting into a narrower composition MUST NOT silently widen to Settings defaults on a transient DB hiccup — matches the tenancy-invariant posture of ``_resolve_composition_selectors`` in ``web_search``. Wired into the two Hatchet tasks that construct ``DecompositionPipeline`` directly: - ``decompose_chunk_task`` (worker-search.workflows.search) - ``decompose_source_task`` (worker-search.workflows.decompose) Worker-nodes call sites (``GatherFactsPipeline``, ``BuildingPipeline``, ``NodePipeline``) go through ``AgentContext`` which doesn't expose ``graph_id`` — threading there lands in the companion #33 PR once ``AgentContext`` grows the knob. 5 new unit tests on the helper cover: composition present, graph_id None fallback, services None fallback, resolver-raises-propagates (authorization guard), unknown-phase-empty-dict. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
… path (Phase 2 #33) Adds the worker-nodes side of Phase 2 ctx threading — the ``bottom_up_scope`` / ``bottom_up_prepare_scope`` workflow tasks now resolve ``fact_decomposition`` phase settings once at task entry (via :func:`kt_hatchet.composition.resolve_phase_settings` added in #32) and forward the dict to :class:`GatherFactsPipeline`, which in turn hands it to every ``DecompositionPipeline`` it constructs via the image-source helper. Call chain closed end-to-end: workflow task ──▶ run_bottom_up_scope_pipeline │ │ │ ▼ │ GatherFactsPipeline(phase_settings=…) │ │ │ ▼ └─── resolve_phase_settings(state, graph_id, "fact_decomposition") │ ▼ _decompose_images_with_session │ ▼ DecompositionPipeline(phase_settings=…) Resolver errors propagate (same fail-fast posture as the search allowlist path in #273 / #277). Worker-nodes' deeper ``BuildingPipeline`` and ``NodePipeline`` ``DecompositionPipeline`` call sites remain on global defaults; they live inside refresh / expand paths that don't have direct task-entry access to ``graph_id`` + ``state.services``. Plumbing them lands with the concrete ``FactDecompositionProvider`` extraction in Phase 4 (#44), which is the first consumer of ``phase_settings`` anyway. 3 new tests on ``GatherFactsPipeline`` plumbing: default empty dict, round-trip of provided settings, ``None`` coerces to ``{}``. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
3 tasks
charlie83Gs
force-pushed
the
feat/worker-phase-settings-threading-v2
branch
from
6418616 to
1dd76c6
Compare
Base automatically changed from
feat/worker-phase-settings-threading-v2
to
main
April 20, 2026 23:15
…phase-settings-threading # Conflicts: # libs/kt-facts/src/kt_facts/pipeline.py # libs/kt-facts/tests/test_pipeline_phase_settings.py
|
I have read the CLA Document and I hereby sign the CLA You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot. |
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.
Summary
Worker-nodes / worker-bottomup side of Phase 2 ctx threading. `bottom_up_scope` + `bottom_up_prepare_scope` now resolve `fact_decomposition` phase_settings once at task entry and forward the dict through `run_bottom_up_scope_pipeline` → `GatherFactsPipeline` → `_decompose_images_with_session` → `DecompositionPipeline`.
Resolver errors propagate — same fail-fast posture as the search allowlist path (#273 / #277). No silent-widen-to-Settings on hiccups.
Scope notes
Worker-nodes' deeper `BuildingPipeline` / `NodePipeline` `DecompositionPipeline` call sites (refresh / expand paths) remain on global defaults; they don't have direct task-entry access to `graph_id` + `state.services`. Those will be threaded with the concrete `FactDecompositionProvider` extraction in Phase 4 (#44) — the first real consumer of `phase_settings` anyway.
Based on #277 (adds `resolve_phase_settings` helper). Rebase once #277 merges.
Test plan
🤖 Generated with Claude Code