Split TreeContext into TreeConfig and OperationState#424
Open
steiler wants to merge 2 commits into
Open
Conversation
`TreeContext` currently holds four fields with fundamentally different lifecycles: - **Setup fields** (SchemaClient, PoolFactory): fixed at tree creation, immutable, shared across all entries and operations - **Operation fields** (ExplicitDeletes, NonRevertiveInfos): reset and accumulated during each operation (import pass, transaction, validation), copied when branching To callers, all four fields look identical. There is no semantic distinction between "this never changes" and "this accumulates per-operation." This creates three problems: 1. **Unclear semantics**: Code reading `e.GetTreeContext().NonRevertiveInfo()` cannot immediately tell whether this reads global config or operation-specific state. 2. **Invisible mutation surface**: Processors and operations mutate `ExplicitDeletes` and `NonRevertiveInfos` as side effects of traversal (e.g., `ImportConfigProcessor.Run` calls `e.GetTreeContext().ExplicitDeletes().Add(...)`). The call-site gives no signal that mutable per-operation state is being written. Phase 1 makes that surface visible via the `OperationState()` accessor; Phase 2 (future PR) will thread `TreeOperationState` explicitly through processor and transaction signatures to eliminate the reach-through entirely. 3. **Accidental sharing**: If a future refactor accidentally fails to deep-copy mutable state during tree branching (DeepCopy), the bug is silent — two branches silently share mutations. ## Solution Split `TreeContext` into two separate concerns: 1. **TreeConfig interface**: immutable, declared in `pkg/tree/api`. Contains SchemaClient and PoolFactory. `TreeContext` self-implements this interface — `TreeConfig()` returns itself, so no separate struct is needed and the interface values are naturally shared across DeepCopy calls. 2. **TreeOperationState interface**: mutable, declared and implemented in `pkg/tree/api`. Created once per tree root, deep-copied when the tree is branched. Contains ExplicitDeletes and NonRevertiveInfos. The `TreeContext` interface is simplified to a lifecycle container (DeepCopy plus the two accessors), and all flat data-access methods are removed. A big-bang migration updates all call sites at once. DeepCopy shares immutable config fields by value (interface reference semantics) and deep-copies TreeOperationState. Benefits: - **Locality**: Reading `tc.TreeConfig()` tells you "this is fixed;" reading `tc.OperationState()` tells you "this accumulates." - **Testability**: TreeOperationState can be tested in isolation from schema and pool setup. - **Safety**: The distinction is enforced at the interface level, reducing the risk of accidental mutation sharing. - **Future leverage**: Sets the stage for Phase 2, where TreeOperationState can be threaded explicitly through processors and transaction flows, eliminating the reach-through mutations entirely. Co-authored-by: Cursor <cursoragent@cursor.com>
…pper Follow-up cleanup on the TreeContext split: - Delete the private `treeConfig` wrapper struct. `TreeContext` now self-implements `api.TreeConfig` — `TreeConfig()` returns `t`, so the immutable fields are shared across DeepCopy calls via interface-value reference semantics with no extra indirection layer. - Rename `OperationState` → `TreeOperationState` (and constructor/method) to align the `Tree*` prefix with `TreeConfig` for consistent naming across both tree-lifecycle types. - Drop the Java-style `Get` prefix: `GetTreeConfig()` → `TreeConfig()`, `GetOperationState()` → `OperationState()`, matching Go getter convention used throughout the rest of the codebase. - Rename `DeepCopyState()` → `DeepCopy()` on `TreeOperationState` now that the receiver type makes the name unambiguous. - Update Behavior 7 test from pointer-identity check on `TreeConfig()` to field-identity check on `SchemaClient()` / `PoolFactory()`, which is the actual invariant now that `TreeConfig()` returns self. Co-authored-by: Cursor <cursoragent@cursor.com>
steiler
force-pushed
the
improveTreeContext
branch
from
43cb6e1 to
a99578d
Compare
Codecov Report❌ Patch coverage is 📢 Thoughts on this report? Let us know! 🚀 New features to boost your workflow:
|
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.
TreeContextcurrently holds four fields with fundamentally different lifecycles:To callers, all four fields look identical. There is no semantic distinction between "this never changes" and "this accumulates per-operation." This creates three problems:
e.GetTreeContext().NonRevertiveInfo()cannot immediately tell whether this reads global config or operation-specific state.ExplicitDeletesandNonRevertiveInfosas side effects of traversal (e.g.,ImportConfigProcessor.Runcallse.GetTreeContext().ExplicitDeletes().Add(...)). A reader must trace deep into multiple call stacks to understand what state is being mutated.Solution
Split
TreeContextinto two separate concerns:The
TreeContextinterface is simplified to a lifecycle marker (DeepCopy plus the two getters), and all flat data-access methods are removed. A big-bang migration updates all call sites at once. DeepCopy reuses the same TreeConfig instance and deep-copies OperationState.Benefits:
GetTreeConfig()tells you "this is fixed;" readingGetOperationState()tells you "this accumulates."