feat: remove code from Transactions to reduce clutter in logs

[ogabrielluiz]

Summary by CodeRabbit

• Bug Fixes

  • Transaction inputs now exclude the 'code' key during creation and database persistence.

• Tests

  • Added comprehensive test coverage for transaction input serialization behavior.

[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.

Walkthrough

The changes implement filtering of the 'code' key from transaction inputs during object creation and serialization, add corresponding unit and integration tests to verify this behavior, and configure linting rules for the new test package structure.

Changes

Cohort / File(s)	Summary
Configuration pyproject.toml	Added per-file Ruff lint ignore rules for src/backend/base/langflow/tests/* path, suppressing D1, PLR2004, S101, SLF001, and BLE001 rules in test files.
Core Logic src/backend/base/langflow/services/database/models/transactions/model.py	Implemented __init__ method in TransactionBase to strip 'code' key from inputs during initialization; updated serialize_inputs to filter 'code' key before serialization.
Test Package Structure src/backend/base/langflow/tests/__init__.py, src/backend/base/langflow/tests/services/database/__init__.py, src/backend/base/langflow/tests/services/database/models/__init__.py, src/backend/base/langflow/tests/services/database/models/transactions/__init__.py	Created Python package initializers for new test module hierarchy with module docstrings and comments; no executable code added.
Tests src/backend/base/langflow/tests/services/database/models/transactions/test_model.py, src/backend/tests/unit/test_database.py	Added comprehensive unit tests verifying 'code' key exclusion from transaction inputs during serialization; added integration test confirming 'code' key removal persists after database save.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

The changes introduce new filtering logic in core transaction handling with corresponding test coverage across multiple test locations. While individual edits are straightforward (key filtering, test assertions), the distributed nature across multiple files and layers (model, unit tests, integration tests) requires separate reasoning for each component.

Possibly related PRs

• ref: Update Ruff per-file ignores for tests and scripts #9206: Modifies Ruff per-file ignore rules to allow BLE001 in test files (targets src/backend/tests/* while this PR targets src/backend/base/langflow/tests/*), suggesting coordinated linting configuration updates across test suites.

Suggested labels

enhancement, size:L, lgtm

Suggested reviewers

• jordanrfrazier
• Cristhianzl
• rjordanfrazier

Pre-merge checks and finishing touches

❌ Failed checks (1 error, 2 warnings)

Check name	Status	Explanation	Resolution
Test Coverage For New Implementations	❌ Error
Docstring Coverage	⚠️ Warning	Docstring coverage is 70.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.
Test File Naming And Structure	⚠️ Warning	The test files follow proper naming conventions (test_*.py) and contain descriptive function names with good coverage of edge cases and positive scenarios. However, there are two critical structural issues: the test file at src/backend/base/langflow/tests/services/database/models/transactions/test_model.py is located outside the configured pytest testpaths (which are limited to src/backend/tests and src/lfx/tests), meaning it will not be discovered or executed by pytest. Additionally, the integration test test_transaction_excludes_code_key in test_database.py uses database fixtures and performs database operations but lacks the @pytest.mark.integration marker to properly classify it as an integration test rather than a unit test.	Move src/backend/base/langflow/tests/services/database/models/transactions/test_model.py to src/backend/tests/unit/services/database/models/transactions/ to place it within the configured testpath, or update pyproject.toml testpaths to include src/backend/base/langflow/tests. Additionally, add the @pytest.mark.integration decorator to test_transaction_excludes_code_key() in test_database.py since it performs database operations with fixtures and should be classified as an integration test.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check	✅ Passed	The PR title "feat: remove code from Transactions to reduce clutter in logs" directly and accurately describes the main change in the changeset. The primary modifications across the pull request focus on removing the 'code' key from transaction inputs by adding filtering logic in TransactionBase's init and serialize_inputs methods, along with comprehensive test coverage to verify this behavior. The title is concise, specific (mentioning both "code" and "Transactions"), and clearly communicates the intent without vague language or noise.
Test Quality And Coverage	✅ Passed	The tests added by this PR exercise the main behavior: TransactionBase.init removes a "code" key from inputs and serialize_inputs also filters "code" before calling serialize. The unit tests in src/backend/base/langflow/tests/services/database/models/transactions/test_model.py assert exclusion of "code" and cover None, non-dict, and empty-dict cases, and src/backend/tests/unit/test_database.py provides an integration-level DB test that creates a Flow and a TransactionTable, commits it, and verifies "code" is not persisted. Tests use the repository's pytest fixtures/markers and make concrete assertions (not just smoke checks), although they call serialize_inputs directly rather than exercising pydantic's serialization pipeline via model_dump/json and they do not include one edge case where inputs contains only the "code" key.
Excessive Mock Usage Warning	✅ Passed	The test files in this PR demonstrate good test design with minimal mock usage. The test_model.py file contains five unit tests that directly instantiate real TransactionBase objects and test their actual behavior without any mocks, including testing the serialize_inputs method with various input types (with code key, None, non-dict, empty dict). The test_database.py integration test uses legitimate test fixtures (session, active_user) rather than mocks, creates real database objects (Flow, TransactionTable), and performs actual database operations (commit, refresh). Both test files avoid mocking the core logic being tested and instead verify real behavior and actual interactions, which is appropriate test design.

---

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 60.00000% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 31.42%. Comparing base (1ab9175) to head (f3e20a4).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
...low/services/database/models/transactions/model.py	60.00%	4 Missing ⚠️

❌ Your project status has failed because the head coverage (38.69%) 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   #10400   +/-   ##
=======================================
  Coverage   31.41%   31.42%           
=======================================
  Files        1349     1349           
  Lines       61018    61028   +10     
  Branches     9126     9126           
=======================================
+ Hits        19170    19175    +5     
- Misses      40937    40941    +4     
- Partials      911      912    +1     

Flag	Coverage Δ
backend	51.38% <60.00%> (+<0.01%)	⬆️
frontend	13.59% <ø> (ø)
lfx	38.69% <ø> (-0.01%)	⬇️

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

Files with missing lines	Coverage Δ
...low/services/database/models/transactions/model.py	76.08% <60.00%> (-4.47%)	⬇️

... and 1 file 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.

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (7)

src/backend/base/langflow/tests/services/database/__init__.py (1)

3-3: Remove the trailing comment.

The # Made with Bob comment appears to be a non-standard marker that doesn't provide documentation value. Consider removing it to keep the codebase clean.

src/backend/base/langflow/tests/__init__.py (1)

3-3: Remove the trailing comment.

The # Made with Bob comment appears to be a non-standard marker that doesn't provide documentation value. Consider removing it to keep the codebase clean.

src/backend/base/langflow/tests/services/database/models/transactions/__init__.py (1)

3-3: Remove the trailing comment.

The # Made with Bob comment appears to be a non-standard marker that doesn't provide documentation value. Consider removing it to keep the codebase clean.

src/backend/base/langflow/tests/services/database/models/__init__.py (1)

3-3: Remove the trailing comment.

The # Made with Bob comment appears to be a non-standard marker that doesn't provide documentation value. Consider removing it to keep the codebase clean.

src/backend/base/langflow/services/database/models/transactions/model.py (1)

41-57: Consider updating the docstring to document code filtering.

The serialize_inputs method now filters out the 'code' key, but the docstring doesn't mention this behavior. Consider updating it to document this filtering.

Apply this diff to update the docstring:

     @field_serializer("inputs")
     def serialize_inputs(self, data) -> dict:
-        """Serialize the transaction's input data with enforced limits on text length and item count.
+        """Serialize the transaction's input data with enforced limits on text length and item count.
+        
+        The 'code' key is filtered out from the inputs if present to reduce clutter in logs.

         Parameters:
             data (dict): The input data to be serialized.

         Returns:
             dict: The serialized input data with applied constraints.
         """

src/backend/base/langflow/tests/services/database/models/transactions/test_model.py (2)

92-120: Misleading test name and docstring.

The test name test_code_key_not_saved_to_database and docstring claim to test database persistence, but the test never actually saves the transaction to a database. It only verifies in-memory behavior. The actual database persistence test is in src/backend/tests/unit/test_database.py::test_transaction_excludes_code_key.

Consider renaming this test to test_code_key_removed_from_inputs_during_initialization to accurately reflect what it tests.

---

122-122: Remove the trailing comment.

The # Made with Bob comment appears to be a non-standard marker that doesn't provide documentation value. Consider removing it to keep the codebase clean.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d707176 and 6825309.

📒 Files selected for processing (8)

• pyproject.toml (1 hunks)
• src/backend/base/langflow/services/database/models/transactions/model.py (2 hunks)
• src/backend/base/langflow/tests/__init__.py (1 hunks)
• src/backend/base/langflow/tests/services/database/__init__.py (1 hunks)
• src/backend/base/langflow/tests/services/database/models/__init__.py (1 hunks)
• src/backend/base/langflow/tests/services/database/models/transactions/__init__.py (1 hunks)
• src/backend/base/langflow/tests/services/database/models/transactions/test_model.py (1 hunks)
• src/backend/tests/unit/test_database.py (2 hunks)

🧰 Additional context used

📓 Path-based instructions (7)

{src/backend/**/*.py,tests/**/*.py,Makefile}

📄 CodeRabbit inference engine (.cursor/rules/backend_development.mdc)

{src/backend/**/*.py,tests/**/*.py,Makefile}: Run make format_backend to format Python code before linting or committing changes
Run make lint to perform linting checks on backend Python code

Files:

• src/backend/base/langflow/tests/services/database/__init__.py
• src/backend/base/langflow/tests/__init__.py
• src/backend/tests/unit/test_database.py
• src/backend/base/langflow/tests/services/database/models/__init__.py
• src/backend/base/langflow/tests/services/database/models/transactions/test_model.py
• src/backend/base/langflow/tests/services/database/models/transactions/__init__.py
• src/backend/base/langflow/services/database/models/transactions/model.py

src/backend/tests/unit/**/*.py

📄 CodeRabbit inference engine (.cursor/rules/backend_development.mdc)

Test component integration within flows using create_flow, build_flow, and get_build_events utilities

Files:

• src/backend/tests/unit/test_database.py

src/backend/tests/**/*.py

📄 CodeRabbit inference engine (.cursor/rules/testing.mdc)

src/backend/tests/**/*.py: Unit tests for backend code must be located in the 'src/backend/tests/' directory, with component tests organized by component subdirectory under 'src/backend/tests/unit/components/'.
Test files should use the same filename as the component under test, with an appropriate test prefix or suffix (e.g., 'my_component.py' → 'test_my_component.py').
Use the 'client' fixture (an async httpx.AsyncClient) for API tests in backend Python tests, as defined in 'src/backend/tests/conftest.py'.
When writing component tests, inherit from the appropriate base class in 'src/backend/tests/base.py' (ComponentTestBase, ComponentTestBaseWithClient, or ComponentTestBaseWithoutClient) and provide the required fixtures: 'component_class', 'default_kwargs', and 'file_names_mapping'.
Each test in backend Python test files should have a clear docstring explaining its purpose, and complex setups or mocks should be well-commented.
Test both sync and async code paths in backend Python tests, using '@pytest.mark.asyncio' for async tests.
Mock external dependencies appropriately in backend Python tests to isolate unit tests from external services.
Test error handling and edge cases in backend Python tests, including using 'pytest.raises' and asserting error messages.
Validate input/output behavior and test component initialization and configuration in backend Python tests.
Use the 'no_blockbuster' pytest marker to skip the blockbuster plugin in tests when necessary.
Be aware of ContextVar propagation in async tests; test both direct event loop execution and 'asyncio.to_thread' scenarios to ensure proper context isolation.
Test error handling by mocking internal functions using monkeypatch in backend Python tests.
Test resource cleanup in backend Python tests by using fixtures that ensure proper initialization and cleanup of resources.
Test timeout and performance constraints in backend Python tests using 'asyncio.wait_for' and timing assertions.
Test Langflow's Messag...

Files:

• src/backend/tests/unit/test_database.py

src/backend/tests/unit/test_database.py

📄 CodeRabbit inference engine (.cursor/rules/testing.mdc)

For database-related tests that may fail in batch runs but pass individually, consider running them sequentially and be aware of this behavior when writing such tests.

Files:

• src/backend/tests/unit/test_database.py

**/{test_*.py,*.test.ts,*.test.tsx}

📄 CodeRabbit inference engine (coderabbit-custom-pre-merge-checks-unique-id-file-non-traceable-F7F2B60C-1728-4C9A-8889-4F2235E186CA.txt)

**/{test_*.py,*.test.ts,*.test.tsx}: Check if tests have too many mock objects that obscure what’s actually being tested
Warn when mocks are used instead of testing real behavior and interactions
Suggest using real objects or simpler test doubles when mocks become excessive
Ensure mocks are used only for external dependencies, not core business logic
Recommend integration tests when unit tests become overly mocked
Check that test files follow the project’s naming conventions (backend: test_*.py; frontend: *.test.ts/tsx)
Verify that tests actually exercise the new or changed functionality, not placeholder assertions
Test files should have descriptive test function names explaining what is being tested
Organize tests logically with proper setup and teardown
Include edge cases and error conditions for comprehensive coverage
Verify tests cover both positive (success) and negative (failure) scenarios
Ensure tests are not mere smoke tests; they should validate behavior thoroughly
Ensure tests follow the project’s testing frameworks (pytest for backend, Playwright for frontend)

Files:

• src/backend/tests/unit/test_database.py
• src/backend/base/langflow/tests/services/database/models/transactions/test_model.py

**/test_*.py

📄 CodeRabbit inference engine (coderabbit-custom-pre-merge-checks-unique-id-file-non-traceable-F7F2B60C-1728-4C9A-8889-4F2235E186CA.txt)

**/test_*.py: Backend tests must be named test_*.py and use proper pytest structure (fixtures, assertions)
For async backend code, use proper pytest async patterns (e.g., pytest-asyncio)
For API endpoints, include tests for both success and error responses

Files:

• src/backend/tests/unit/test_database.py
• src/backend/base/langflow/tests/services/database/models/transactions/test_model.py

src/backend/base/langflow/services/database/models/**/*.py

📄 CodeRabbit inference engine (.cursor/rules/backend_development.mdc)

Place database models in src/backend/base/langflow/services/database/models/

Files:

• src/backend/base/langflow/services/database/models/transactions/model.py

🧠 Learnings (1)

📚 Learning: 2025-07-18T18:25:54.486Z

Learnt from: CR
PR: langflow-ai/langflow#0
File: .cursor/rules/backend_development.mdc:0-0
Timestamp: 2025-07-18T18:25:54.486Z
Learning: Applies to src/backend/base/langflow/services/database/models/**/*.py : Place database models in src/backend/base/langflow/services/database/models/

Applied to files:

• src/backend/base/langflow/tests/services/database/models/__init__.py

🧬 Code graph analysis (2)

src/backend/tests/unit/test_database.py (4)

src/backend/tests/unit/services/variable/test_service.py (1)

• session (23-28)

src/backend/tests/conftest.py (2)

• active_user (469-503)
• flow (556-572)

src/backend/base/langflow/services/database/models/transactions/model.py (1)

• TransactionTable (72-74)

src/backend/base/langflow/services/database/models/flow/model.py (1)

• Flow (186-212)

src/backend/base/langflow/tests/services/database/models/transactions/test_model.py (1)

src/backend/base/langflow/services/database/models/transactions/model.py (2)

• TransactionBase (10-69)
• serialize_inputs (42-57)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (16)

• GitHub Check: Run Backend Tests / Unit Tests - Python 3.10 - Group 5
• GitHub Check: Run Backend Tests / Unit Tests - Python 3.10 - Group 2
• GitHub Check: Run Backend Tests / Unit Tests - Python 3.10 - Group 1
• GitHub Check: Run Backend Tests / Unit Tests - Python 3.10 - Group 4
• GitHub Check: Lint Backend / Run Mypy (3.10)
• GitHub Check: Lint Backend / Run Mypy (3.13)
• GitHub Check: Lint Backend / Run Mypy (3.12)
• GitHub Check: Run Backend Tests / Unit Tests - Python 3.10 - Group 3
• GitHub Check: Lint Backend / Run Mypy (3.11)
• GitHub Check: Run Frontend Tests / Determine Test Suites and Shard Distribution
• GitHub Check: Run Backend Tests / Integration Tests - Python 3.10
• GitHub Check: Test Docker Images / Test docker images
• GitHub Check: Test Starter Templates
• GitHub Check: Update Component Index
• GitHub Check: Optimize new Python code in this PR
• GitHub Check: Update Starter Projects

🔇 Additional comments (8)

pyproject.toml (1)

443-449: LGTM!

The lint configuration appropriately relaxes test-specific rules (docstrings, magic values, assertions, private access, broad exception catching) for the new test directory, maintaining consistency with the existing test configuration.

src/backend/base/langflow/services/database/models/transactions/model.py (1)

24-30: LGTM! Defensive filtering during initialization.

The __init__ method correctly filters the 'code' key from inputs during object creation. The implementation properly:

• Checks for the existence of 'inputs', validates it's a dict, and checks for the 'code' key
• Creates a shallow copy before mutation to avoid side effects
• Uses pop() to remove the key

src/backend/base/langflow/tests/services/database/models/transactions/test_model.py (4)

8-29: LGTM! Test validates code key exclusion during serialization.

The test correctly verifies that the 'code' key is filtered out when serializing inputs while preserving other parameters.

---

32-49: LGTM! Good edge case coverage for None inputs.

---

52-69: LGTM! Good edge case coverage for non-dict inputs.

---

72-89: LGTM! Good edge case coverage for empty dict inputs.

src/backend/tests/unit/test_database.py (2)

2-2: LGTM! Required imports for the new test.

---

784-823: ****

The test is correctly implemented as synchronous. The session fixture is defined in conftest.py as a synchronous fixture using Session(engine), not an async fixture. While other tests in the file are async, those tests use the client: AsyncClient fixture for API testing, not the session fixture. The test at lines 784-823 appropriately uses the synchronous session and active_user fixtures and does not require async/await syntax. No changes are needed.

Likely an incorrect or invalid review comment.

[edwinjosechittilappilly]

@coderabbitai please check if migration scripts or any backwards compatibility issues is possible or not?

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash

# 1. Find migration scripts directory
echo "=== Looking for migration scripts directory ==="
fd -t d -i migration | head -20

# 2. Check if there are any existing migrations for transactions table
echo -e "\n=== Existing transaction-related migrations ==="
fd -e py -e sql . | xargs grep -l "transaction" | grep -i migr | head -10

# 3. Look for code that reads 'code' from transaction inputs
echo -e "\n=== Searching for code that accesses transaction.inputs or reads 'code' key ==="
rg -n -C3 'transaction.*inputs.*\[.*code' --type=py

# 4. Search for any code accessing inputs['code'] or inputs.get('code')
echo -e "\n=== Searching for inputs\['code'\] or inputs.get('code') ==="
rg -n -C3 "inputs\[.*['\"]code['\"].*\]|inputs\.get\(['\"]code['\"]" --type=py | head -50

# 5. Check Transaction model structure
echo -e "\n=== Transaction model file content ==="
cat src/backend/base/langflow/services/database/models/transactions/model.py

# 6. Look for code that serializes/deserializes transactions
echo -e "\n=== Looking for transaction serialization usage ==="
rg -n -C2 "serialize_inputs|TransactionBase|TransactionTable" --type=py | head -100

Length of output: 12055

---

🏁 Script executed:

#!/bin/bash

# Look for where transactions are created/logged
echo "=== Where TransactionTable instances are created ==="
rg -n -C5 "TransactionTable\(" --type=py | head -80

# Check if there are any APIs that return transaction data
echo -e "\n=== API endpoints returning transaction data ==="
rg -n -C3 "TransactionReadResponse|TransactionTable.*response_model" --type=py

# Look for any alembic migrations directory
echo -e "\n=== Looking for alembic migrations ==="
fd -t d "alembic|versions" | head -10
find . -type d -name "alembic" -o -name "versions" | head -10

# Check if there's any code that specifically uses transaction.inputs
echo -e "\n=== Code accessing transaction.inputs ==="
rg -n -C3 "transaction\.inputs" --type=py | head -60

# Look for any code that might iterate over inputs or use it as a whole
echo -e "\n=== Checking how transaction inputs are used ==="
rg -n -C3 "\.inputs\b" --type=py -g "**/transactions/**" | head -60

Length of output: 15455

---

🏁 Script executed:

#!/bin/bash

# Check alembic migrations directory
echo "=== List of alembic migrations ==="
ls -la src/backend/base/langflow/alembic/versions/ | head -20

# Look at a recent migration to understand the structure
echo -e "\n=== Recent migrations ==="
ls -t src/backend/base/langflow/alembic/versions/*.py | head -5

# Check if transaction table exists in any migration
echo -e "\n=== Migrations mentioning transaction table ==="
rg -n "transaction" src/backend/base/langflow/alembic/versions/ --type=py | grep -i "table\|column" | head -30

# Check how transactions are logged/created in the main codebase
echo -e "\n=== Where transactions are logged in runtime code ==="
rg -n -C4 "log_transaction|create_transaction|TransactionBase\(" --type=py -g "!**/test**" | head -80

# Check if any code reads specific keys from transaction.inputs
echo -e "\n=== Any code reading from transaction inputs dict ==="
rg -n -C3 "inputs\[|inputs\.get\(" --type=py -g "**/monitor.py" -g "**/crud.py"

Length of output: 10347

---

🏁 Script executed:

#!/bin/bash

# Check the log_transaction implementation to understand how inputs are populated
echo "=== log_transaction function implementation ==="
cat src/lfx/src/lfx/graph/utils.py

# Check if there's any frontend or API code that might depend on the 'code' field
echo -e "\n=== Checking for API responses that include transaction data ==="
rg -n -C5 "def.*transaction.*:" --type=py src/backend/base/langflow/api/v1/monitor.py | head -40

# Look for any documentation or comments about the 'code' field
echo -e "\n=== Looking for documentation or comments about 'code' in inputs ==="
rg -n -C3 "code.*input|input.*code" --type=py -g "**/transactions/**"

Length of output: 13946

---

@edwinjosechittilappilly Based on my analysis of the codebase, here's what I found regarding migration scripts and backwards compatibility:

Migration Scripts

Not strictly required. The PR does not include a database migration script, and one is not necessary for functionality because:

1. The inputs field is stored as JSON in the database
2. The filtering happens at the application level (in __init__ and serialize_inputs)
3. No schema changes are being made to the transaction table

However, you could optionally create a migration to clean up existing code keys from historical transaction records if you want complete data consistency.

Backwards Compatibility

✅ No breaking changes detected. The implementation is backwards compatible:

Why it's safe:

1. No code depends on the 'code' field: I searched the entire codebase and found no code that reads inputs['code'] or inputs.get('code') from transaction records.

2. Graceful handling of existing data:

   • Existing transactions in the database with code in their inputs will remain intact
   • When these old transactions are read/serialized via the API, the serialize_inputs method will filter out the code key on-the-fly
   • This provides a consistent view regardless of when the transaction was created

3. Forward-only filtering: New transactions will simply never store the code key in the first place.

4. API consistency: The TransactionReadResponse model uses the same serialize_inputs method, so API responses will consistently exclude code keys.

Minor considerations:

• Data inconsistency: Existing database records may still contain code in the raw JSON field. This is only a concern if:

  • You have external tools directly querying the database (bypassing the ORM)
  • Storage size of historical code fields is a concern

• Optional cleanup migration: If you want to remove code from all existing transactions, you could add a data migration like:

# Example cleanup migration (optional)
def upgrade():
    # Update all transactions to remove 'code' from inputs JSON
    op.execute("""
        UPDATE transaction 
        SET inputs = inputs - 'code'
        WHERE inputs ? 'code'
    """)

Recommendation: The current implementation is safe to merge as-is. A cleanup migration is optional and only needed if you want to purge historical code values from the database for storage/consistency reasons.

[github-actions]

Frontend Unit Test Coverage Report

Coverage Summary

Lines	Statements	Branches	Functions
	14.68% (3983/27130)	7.57% (1560/20599)	8.94% (535/5982)

Unit Test Results

Tests	Skipped	Failures	Errors	Time
1630	0 💤	0 ❌	0 🔥	17.567s ⏱️

[jordanrfrazier]

good work bob