fix: Clear input fields data operations

[HimavarshaVS]

Description

The "Data Operations" component fails to reset its UI state when an operation is removed. When a user selects an operation (e.g., "Filter Values"), the component correctly displays the necessary input fields. However, clicking the "X" to remove the operation only removes the operation's name, leaving the associated input fields (Filter Key, Comparison Operator, etc.) orphaned on the component UI. In contrast, the "Text Operations" component (which shares a similar logic) behaves as expected by clearing all inputs upon removal.

Steps to reproduce

operations.mov

Summary by CodeRabbit

Release Notes

• New Features

  • Operation-specific input fields now automatically hide when no operation is selected, improving UI clarity.
  • Enhanced default values for input fields to ensure consistent state initialization.

• Tests

  • Added test coverage for field visibility behavior when operations are removed.

[coderabbitai]

Important

Review skipped

Auto incremental reviews are disabled on this repository.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

Walkthrough

This PR adds explicit UI state management for operation-specific fields in the DataOperationsComponent. When the operations array is cleared, operation-related fields are now hidden and reset to default values. Changes span backend logic, frontend UI updates, test coverage, and asset metadata.

Changes

Cohort / File(s)	Summary
Backend Implementation src/lfx/src/lfx/components/processing/data_operations.py, src/lfx/src/lfx/_assets/component_index.json, src/lfx/src/lfx/_assets/stable_hash_history.json	Introduced ALL_OPERATION_FIELDS and OPERATION_FIELD_DEFAULTS class attributes for centralized field state management. Enhanced update_build_config to hide and reset all operation-specific fields when operations array is cleared. Updated input field initializations with explicit default values. Updated component metadata hash and asset definitions to reflect new public attributes.
Frontend Integration src/frontend/src/CustomNodes/hooks/use-handle-new-value.ts	Added DATA_OPERATIONS_OPERATION_FIELDS constant and optimistic UI logic to hide operation-specific fields before API response when operations array is empty for Data Operations component.
Test Coverage src/backend/tests/unit/components/processing/test_data_operations_component.py	Added test_update_build_config_clears_input_fields_when_operation_removed test method validating that operation-specific fields are hidden and default fields remain visible when no operation is selected.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

---

Important

Pre-merge checks failed

Please resolve all errors before merging. Addressing warnings is optional.

❌ Failed checks (1 error, 3 warnings, 1 inconclusive)

Check name	Status	Explanation	Resolution
Test Coverage For New Implementations	❌ Error	PR adds incomplete test coverage: backend test checks only 4 of 10 operation fields and lacks value reset assertions; frontend hook changes have no test coverage.	Extend backend test to cover all 10 fields with both show and value assertions; create frontend test file for use-handle-new-value.ts hook to verify field clearing behavior.
Docstring Coverage	⚠️ Warning	Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.
Test Quality And Coverage	⚠️ Warning	Test coverage for new functionality is insufficient, covering only 4 of 10 operation fields and missing frontend hook tests.	Expand backend test to cover all 10 operation fields with assertions for both show and value properties, and create frontend hook test file.
Test File Naming And Structure	⚠️ Warning	PR modifies frontend code without adding corresponding tests and backend test has incomplete field coverage with missing value reset assertions.	Add frontend test file for use-handle-new-value.ts hook and expand backend test to cover all 10 operation fields with value reset assertions.
Title check	❓ Inconclusive	The title 'fix: Clear input fields data operations' is generic and lacks specificity; it fails to clearly convey the primary change that operation-specific input fields should be hidden when no operation is selected.	Consider using a more descriptive title like 'fix: Hide operation fields when operation is removed' to better clarify the specific behavior being corrected.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Excessive Mock Usage Warning	✅ Passed	The new test demonstrates appropriate and minimal mock usage with real objects throughout.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch clear-input-fields-data-operations

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[codecov]

Codecov Report

❌ Patch coverage is 0% with 7 lines in your changes missing coverage. Please review.
✅ Project coverage is 35.31%. Comparing base (f44e2b3) to head (ed02908).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
...tend/src/CustomNodes/hooks/use-handle-new-value.ts	0.00%	7 Missing ⚠️

❌ Your patch status has failed because the patch coverage (0.00%) is below the target coverage (40.00%). You can increase the patch coverage or adjust the target coverage.
❌ Your project status has failed because the head coverage (42.03%) is below the target coverage (60.00%). You can increase the head coverage or adjust the target coverage.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #11773      +/-   ##
==========================================
- Coverage   35.31%   35.31%   -0.01%     
==========================================
  Files        1525     1525              
  Lines       73292    73299       +7     
  Branches    11021    11025       +4     
==========================================
+ Hits        25884    25885       +1     
- Misses      45995    46000       +5     
- Partials     1413     1414       +1     

Flag	Coverage Δ
backend	55.78% <ø> (+0.01%)	⬆️
frontend	16.99% <0.00%> (-0.01%)	⬇️
lfx	42.03% <ø> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
...tend/src/CustomNodes/hooks/use-handle-new-value.ts	0.00% <0.00%> (ø)

... and 9 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

Frontend Unit Test Coverage Report

Coverage Summary

Lines	Statements	Branches	Functions
	18.81% (6095/32401)	12.25% (3097/25275)	12.64% (879/6951)

Unit Test Results

Tests	Skipped	Failures	Errors	Time
2310	0 💤	0 ❌	0 🔥	32.555s ⏱️

[viktoravelino]

fe code looks good to me

[coderabbitai]

Actionable comments posted: 3

🧹 Nitpick comments (5)

src/lfx/src/lfx/components/processing/data_operations.py (2)

498-503: Redundant inner check: every ALL_OPERATION_FIELDS entry exists in OPERATION_FIELD_DEFAULTS.

The if field in self.OPERATION_FIELD_DEFAULTS guard on line 502 is always True because both lists are defined with identical keys. Simplify to a direct access or use .get() for defensive coding:

Suggested simplification

             for field in self.ALL_OPERATION_FIELDS:
                 if field in build_config:
                     build_config[field]["show"] = False
-                    if field in self.OPERATION_FIELD_DEFAULTS:
-                        build_config[field]["value"] = self.OPERATION_FIELD_DEFAULTS[field]
+                    build_config[field]["value"] = deepcopy(self.OPERATION_FIELD_DEFAULTS[field])

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lfx/src/lfx/components/processing/data_operations.py` around lines 498 -
503, The inner conditional checking membership in OPERATION_FIELD_DEFAULTS is
redundant because ALL_OPERATION_FIELDS entries are guaranteed to exist there;
simplify the loop in the method that iterates ALL_OPERATION_FIELDS by directly
assigning build_config[field]["value"] = self.OPERATION_FIELD_DEFAULTS[field]
(or use self.OPERATION_FIELD_DEFAULTS.get(field) for defensive style) after
setting build_config[field]["show"] = False; this change affects the block
referencing ALL_OPERATION_FIELDS, OPERATION_FIELD_DEFAULTS, and build_config in
data_operations.py.

---

248-261: DRY: OPERATION_FIELD_DEFAULTS duplicates values from input declarations.

The defaults for operator, append_update_data, rename_keys_input, etc. are already declared in the inputs list (lines 135–247). Maintaining them in two places invites divergence. Consider deriving defaults programmatically from the input definitions:

OPERATION_FIELD_DEFAULTS = {
    inp.name: inp.value
    for inp in inputs
    if inp.name in ALL_OPERATION_FIELDS
}

This was also raised in the PR review comments by Cristhianzl.

Also applies to: 84-96

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lfx/src/lfx/components/processing/data_operations.py` around lines 248 -
261, OPERATION_FIELD_DEFAULTS currently duplicates default values already
declared on the Input definitions; replace the hard-coded dict with a derived
one by iterating over the inputs list and selecting entries whose names appear
in ALL_OPERATION_FIELDS (e.g., OPERATION_FIELD_DEFAULTS = {inp.name: inp.value
for inp in inputs if inp.name in ALL_OPERATION_FIELDS}), and apply the same
replacement for the earlier duplicated block around the symbols referenced at
lines 84–96; ensure the derived defaults preserve the original value objects
(not copies) and keep the same key set as the original constant.

src/frontend/src/CustomNodes/hooks/use-handle-new-value.ts (1)

16-28: Cross-stack duplication: field list must be kept in sync manually.

DATA_OPERATIONS_OPERATION_FIELDS duplicates ALL_OPERATION_FIELDS from data_operations.py. The sync comment helps, but any backend field addition/removal will silently desync the frontend. Consider deriving this list from the node template at runtime (e.g., from node.template or an API-exposed field list) to eliminate the manual coupling.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/frontend/src/CustomNodes/hooks/use-handle-new-value.ts` around lines 16 -
28, DATA_OPERATIONS_OPERATION_FIELDS in use-handle-new-value.ts duplicates
ALL_OPERATION_FIELDS from data_operations.py and must be kept manually in sync;
replace the hardcoded array by deriving the field list at runtime from the node
template or an API to avoid drift — e.g., update the logic in useHandleNewValue
(or the module exporting DATA_OPERATIONS_OPERATION_FIELDS) to read node.template
(or call the backend endpoint that returns operation field names) and build the
equivalent array dynamically, falling back to the current static list only if
the template/API is unavailable.

src/lfx/src/lfx/_assets/component_index.json (2)

95583-95583: OPERATION_FIELD_DEFAULTS duplicates the default values already declared in the inputs list.

For example, "operator": "equals" appears in both OPERATION_FIELD_DEFAULTS and the DropdownInput(name="operator", ..., value="equals") definition. If a default ever changes in one place but not the other, the reset behavior will silently diverge. The reviewer already suggested deriving defaults programmatically from the inputs definitions. Consider adopting that approach to keep a single source of truth.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lfx/src/lfx/_assets/component_index.json` at line 95583,
OPERATION_FIELD_DEFAULTS duplicates defaults defined in the inputs list (e.g.,
"operator" default "equals"); replace the hard-coded OPERATION_FIELD_DEFAULTS
with a programmatic generator that iterates over the inputs list and builds the
defaults map from each input's declared value (and appropriate empty defaults
for is_list inputs), ensuring keys from ALL_OPERATION_FIELDS are included;
update the class to compute this generated defaults (e.g., at class definition
time or in a small helper like build_operation_field_defaults()) and keep
update_build_config using that generated OPERATION_FIELD_DEFAULTS so there is a
single source of truth for default values.

---

95583-95583: Redundant if field in self.OPERATION_FIELD_DEFAULTS check inside update_build_config.

Every entry in ALL_OPERATION_FIELDS has a corresponding key in OPERATION_FIELD_DEFAULTS, so the inner guard is always True. This was also flagged by the reviewer. Simplify by removing the redundant check or, for extra safety, use .get().

Proposed simplification

In the update_build_config method:

             for field in self.ALL_OPERATION_FIELDS:
                 if field in build_config:
                     build_config[field]["show"] = False
-                    if field in self.OPERATION_FIELD_DEFAULTS:
-                        build_config[field]["value"] = self.OPERATION_FIELD_DEFAULTS[field]
+                    build_config[field]["value"] = self.OPERATION_FIELD_DEFAULTS[field]

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lfx/src/lfx/_assets/component_index.json` at line 95583, The loop in
update_build_config iterates ALL_OPERATION_FIELDS and then redundantly checks if
field in OPERATION_FIELD_DEFAULTS before resetting values; remove that inner
guard and directly reset show and set the default using
OPERATION_FIELD_DEFAULTS.get(field) (or assume presence and index
OPERATION_FIELD_DEFAULTS[field]) so each field is hidden and its value reset
consistently; update_build_config, ALL_OPERATION_FIELDS and
OPERATION_FIELD_DEFAULTS are the symbols to change.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@src/backend/tests/unit/components/processing/test_data_operations_component.py`:
- Around line 195-223: The test for DataOperationsComponent.update_build_config
is incomplete: extend the mock build_config to include all operation-specific
keys (append_update_data, remove_keys_input, rename_keys_input,
mapped_json_display, selected_key, query, etc.) so their show flags are
exercised, and add assertions that values are reset to OPERATION_FIELD_DEFAULTS
(e.g., assert result["operator"]["value"] equals the expected default and
similarly for other fields) after calling component.update_build_config;
reference the DataOperationsComponent class and its update_build_config method
and use the same field names (filter_key, operator, filter_values,
select_keys_input, append_update_data, remove_keys_input, rename_keys_input,
mapped_json_display, selected_key, query) to add both show=false and
value==OPERATION_FIELD_DEFAULTS checks.

In `@src/lfx/src/lfx/_assets/component_index.json`:
- Line 95583: The as_data method assumes every item in self.operations is a dict
with a "name" key which can raise KeyError/TypeError; change the
selected_actions extraction in as_data to the same defensive pattern used in
update_build_config (filtering with isinstance(action, dict) and "name" in
action) when building selected_actions from self.operations, ensuring you handle
empty/malformed entries gracefully before looking up action_map and invoking
handlers.

In `@src/lfx/src/lfx/components/processing/data_operations.py`:
- Around line 248-261: OPERATION_FIELD_DEFAULTS currently contains mutable
shared instances and the assignment build_config[field]["value"] =
self.OPERATION_FIELD_DEFAULTS[field] binds those shared objects; change the
assignment to provide a fresh copy (e.g., use
copy.deepcopy(self.OPERATION_FIELD_DEFAULTS[field]) or replace
OPERATION_FIELD_DEFAULTS with a function like get_operation_field_defaults()
that returns new dict/list instances) so each build_config gets its own
independent mutable objects and class-level defaults are not mutated by
consumers.

---

Nitpick comments:
In `@src/frontend/src/CustomNodes/hooks/use-handle-new-value.ts`:
- Around line 16-28: DATA_OPERATIONS_OPERATION_FIELDS in use-handle-new-value.ts
duplicates ALL_OPERATION_FIELDS from data_operations.py and must be kept
manually in sync; replace the hardcoded array by deriving the field list at
runtime from the node template or an API to avoid drift — e.g., update the logic
in useHandleNewValue (or the module exporting DATA_OPERATIONS_OPERATION_FIELDS)
to read node.template (or call the backend endpoint that returns operation field
names) and build the equivalent array dynamically, falling back to the current
static list only if the template/API is unavailable.

In `@src/lfx/src/lfx/_assets/component_index.json`:
- Line 95583: OPERATION_FIELD_DEFAULTS duplicates defaults defined in the inputs
list (e.g., "operator" default "equals"); replace the hard-coded
OPERATION_FIELD_DEFAULTS with a programmatic generator that iterates over the
inputs list and builds the defaults map from each input's declared value (and
appropriate empty defaults for is_list inputs), ensuring keys from
ALL_OPERATION_FIELDS are included; update the class to compute this generated
defaults (e.g., at class definition time or in a small helper like
build_operation_field_defaults()) and keep update_build_config using that
generated OPERATION_FIELD_DEFAULTS so there is a single source of truth for
default values.
- Line 95583: The loop in update_build_config iterates ALL_OPERATION_FIELDS and
then redundantly checks if field in OPERATION_FIELD_DEFAULTS before resetting
values; remove that inner guard and directly reset show and set the default
using OPERATION_FIELD_DEFAULTS.get(field) (or assume presence and index
OPERATION_FIELD_DEFAULTS[field]) so each field is hidden and its value reset
consistently; update_build_config, ALL_OPERATION_FIELDS and
OPERATION_FIELD_DEFAULTS are the symbols to change.

In `@src/lfx/src/lfx/components/processing/data_operations.py`:
- Around line 498-503: The inner conditional checking membership in
OPERATION_FIELD_DEFAULTS is redundant because ALL_OPERATION_FIELDS entries are
guaranteed to exist there; simplify the loop in the method that iterates
ALL_OPERATION_FIELDS by directly assigning build_config[field]["value"] =
self.OPERATION_FIELD_DEFAULTS[field] (or use
self.OPERATION_FIELD_DEFAULTS.get(field) for defensive style) after setting
build_config[field]["show"] = False; this change affects the block referencing
ALL_OPERATION_FIELDS, OPERATION_FIELD_DEFAULTS, and build_config in
data_operations.py.
- Around line 248-261: OPERATION_FIELD_DEFAULTS currently duplicates default
values already declared on the Input definitions; replace the hard-coded dict
with a derived one by iterating over the inputs list and selecting entries whose
names appear in ALL_OPERATION_FIELDS (e.g., OPERATION_FIELD_DEFAULTS =
{inp.name: inp.value for inp in inputs if inp.name in ALL_OPERATION_FIELDS}),
and apply the same replacement for the earlier duplicated block around the
symbols referenced at lines 84–96; ensure the derived defaults preserve the
original value objects (not copies) and keep the same key set as the original
constant.

[coderabbitai]

🛠️ Refactor suggestion | 🟠 Major

Test coverage gaps: missing fields and value-reset assertions.

Two gaps worth addressing:

1. Only 4 of 10 operation fields are included in the mock build_config. Fields like append_update_data, remove_keys_input, rename_keys_input, mapped_json_display, selected_key, and query are absent, so their hide behavior goes untested.

2. Value reset is not asserted. The update_build_config method also resets field values to OPERATION_FIELD_DEFAULTS, but this test only checks show. Adding assertions like assert result["operator"]["value"] == "equals" would confirm the reset path.

Suggested additions

         build_config = dotdict(
             {
                 "operations": {"value": [], "show": True},
                 "data": {"value": None, "show": True},
                 "filter_key": {"value": [], "show": True},
                 "operator": {"value": "equals", "show": True},
                 "filter_values": {"value": {}, "show": True},
                 "select_keys_input": {"value": [], "show": False},
+                "append_update_data": {"value": {"key": "value"}, "show": True},
+                "remove_keys_input": {"value": ["something"], "show": True},
+                "rename_keys_input": {"value": {"a": "b"}, "show": True},
+                "mapped_json_display": {"value": "some json", "show": True},
+                "selected_key": {"value": ".foo", "show": True},
+                "query": {"value": ".bar", "show": True},
             }
         )
         result = component.update_build_config(build_config, [], "operations")
 
         # All operation-specific fields should be hidden when no operation is selected
         assert result["filter_key"]["show"] is False
         assert result["operator"]["show"] is False
         assert result["filter_values"]["show"] is False
         assert result["select_keys_input"]["show"] is False
+        assert result["append_update_data"]["show"] is False
+        assert result["remove_keys_input"]["show"] is False
+        assert result["rename_keys_input"]["show"] is False
+        assert result["mapped_json_display"]["show"] is False
+        assert result["selected_key"]["show"] is False
+        assert result["query"]["show"] is False
+
+        # Values should be reset to defaults
+        assert result["operator"]["value"] == "equals"
+        assert result["remove_keys_input"]["value"] == []
+        assert result["rename_keys_input"]["value"] == {"old_key": "new_key"}
+        assert result["query"]["value"] == ""
         # Default fields (operations, data) should remain visible
         assert result["operations"]["show"] is True
         assert result["data"]["show"] is True

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/backend/tests/unit/components/processing/test_data_operations_component.py`
around lines 195 - 223, The test for DataOperationsComponent.update_build_config
is incomplete: extend the mock build_config to include all operation-specific
keys (append_update_data, remove_keys_input, rename_keys_input,
mapped_json_display, selected_key, query, etc.) so their show flags are
exercised, and add assertions that values are reset to OPERATION_FIELD_DEFAULTS
(e.g., assert result["operator"]["value"] equals the expected default and
similarly for other fields) after calling component.update_build_config;
reference the DataOperationsComponent class and its update_build_config method
and use the same field names (filter_key, operator, filter_values,
select_keys_input, append_update_data, remove_keys_input, rename_keys_input,
mapped_json_display, selected_key, query) to add both show=false and
value==OPERATION_FIELD_DEFAULTS checks.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Inconsistent defensiveness when extracting selected_actions in as_data vs update_build_config.

In update_build_config, the extraction of action names is defensive:

selected_actions = [
    action["name"] for action in (field_value or []) if isinstance(action, dict) and "name" in action
]

But in as_data, the extraction assumes every item in self.operations is a dict with a "name" key:

selected_actions = [action["name"] for action in self.operations]

If self.operations ever contains a malformed entry (e.g., a string or a dict without "name"), as_data will raise a KeyError/TypeError at runtime. Consider using the same guard pattern.

Proposed fix

In the embedded as_data method (within the JSON "value" string and the corresponding .py source):

-        selected_actions = [action["name"] for action in self.operations]
+        selected_actions = [
+            action["name"] for action in self.operations if isinstance(action, dict) and "name" in action
+        ]

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lfx/src/lfx/_assets/component_index.json` at line 95583, The as_data
method assumes every item in self.operations is a dict with a "name" key which
can raise KeyError/TypeError; change the selected_actions extraction in as_data
to the same defensive pattern used in update_build_config (filtering with
isinstance(action, dict) and "name" in action) when building selected_actions
from self.operations, ensuring you handle empty/malformed entries gracefully
before looking up action_map and invoking handlers.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

Mutable default values shared by reference — will corrupt future resets.

OPERATION_FIELD_DEFAULTS contains mutable objects ([], {}, {"key": "value"}). The assignment on line 503:

build_config[field]["value"] = self.OPERATION_FIELD_DEFAULTS[field]

binds the same list/dict instance to build_config. If any downstream code mutates that value in-place (e.g., .append(), [key] = ...), it permanently corrupts the class-level defaults for all subsequent calls.

Fix: deep-copy defaults on assignment

+from copy import deepcopy
 ...
             for field in self.ALL_OPERATION_FIELDS:
                 if field in build_config:
                     build_config[field]["show"] = False
                     if field in self.OPERATION_FIELD_DEFAULTS:
-                        build_config[field]["value"] = self.OPERATION_FIELD_DEFAULTS[field]
+                        build_config[field]["value"] = deepcopy(self.OPERATION_FIELD_DEFAULTS[field])

Alternatively, make OPERATION_FIELD_DEFAULTS a method that returns fresh copies each time.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lfx/src/lfx/components/processing/data_operations.py` around lines 248 -
261, OPERATION_FIELD_DEFAULTS currently contains mutable shared instances and
the assignment build_config[field]["value"] =
self.OPERATION_FIELD_DEFAULTS[field] binds those shared objects; change the
assignment to provide a fresh copy (e.g., use
copy.deepcopy(self.OPERATION_FIELD_DEFAULTS[field]) or replace
OPERATION_FIELD_DEFAULTS with a function like get_operation_field_defaults()
that returns new dict/list instances) so each build_config gets its own
independent mutable objects and class-level defaults are not mutated by
consumers.