fix: update pydantic to 2.12.5 for fastapi-pagination compatibility

[ogabrielluiz]

Summary

Updates dependencies for fastapi-pagination compatibility:

1. Pydantic ~=2.11.0 → ~=2.12.5

   • Required by fastapi-pagination to avoid deprecation warning:

   Pydantic v2.12.5 or higher is required for full compatibility. Support for Pydantic versions lower than v2.12.5 will be dropped in fastapi-pagination v0.16.0.

2. SQLModel ==0.0.22 → >=0.0.32,<1.0.0

   • SQLModel 0.0.32 includes the fix for Annotated field handling with Pydantic 2.12+ (PR #1607 by @vimota)
   • Without this upgrade, runtime type-mapping errors occur when using Annotated type hints with SQLModel models

3. TransactionReadResponse model_config fix

   • Added populate_by_name=True and from_attributes=True to TransactionReadResponse
   • With Pydantic 2.12+, model_validate with from_attributes=True requires populate_by_name=True when using field aliases

SQLModel 0.0.32 Changelog

From the release notes:

🐛 Fix support for Annotated fields with Pydantic 2.12+. PR #1607 by @vimota

This fix resolves issues where SQLModel models with Annotated type hints were not properly supported in newer Pydantic versions.

[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

A pydantic dependency version constraint is updated from ~=2.11.0 to ~=2.12.5 in the project configuration file, adjusting the allowable release range for the pydantic library.

Changes

Cohort / File(s)	Summary
Dependency Update src/backend/base/pyproject.toml	Updated pydantic version constraint from ~=2.11.0 to ~=2.12.5, expanding the supported release range.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

🚥 Pre-merge checks | ✅ 6 | ❌ 1

❌ Failed checks (1 error)

Check name	Status	Explanation	Resolution
Test Coverage For New Implementations	❌ Error	PR upgrades Pydantic to 2.12.5 for fastapi-pagination compatibility but lacks tests for known Pydantic 2.12.5 + sqlmodel 0.0.22 breaking changes causing runtime type-mapping errors.	Add regression tests for Pydantic 2.12.5 + sqlmodel 0.0.22 compatibility, or upgrade sqlmodel to 0.0.32+ (released Feb 1, 2026) with corresponding integration tests.

✅ Passed checks (6 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main change: updating pydantic to 2.12.5 for fastapi-pagination compatibility, which matches the single-line dependency update in the changeset.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Test Quality And Coverage	✅ Passed	This PR updates a dependency version constraint in pyproject.toml, not implementing new functionality. The Test Quality and Coverage check is designed for new implementations and is not applicable to dependency version updates.
Test File Naming And Structure	✅ Passed	The custom check for test file naming and structure is not applicable to this pull request. The PR contains only a single-line dependency version update in src/backend/base/pyproject.toml and does not modify, add, or remove any test files.
Excessive Mock Usage Warning	✅ Passed	The custom check for excessive mock usage in test files is not applicable to this PR, which only modifies pyproject.toml with no test file changes.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/pagination-warning

---

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

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 37.31%. Comparing base (5a18aaa) to head (de1a511).
⚠️ Report is 1 commits behind head on main.

❌ Your project status has failed because the head coverage (42.29%) 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   #11566      +/-   ##
==========================================
- Coverage   37.32%   37.31%   -0.01%     
==========================================
  Files        1592     1592              
  Lines       78279    78280       +1     
  Branches    11824    11824              
==========================================
- Hits        29216    29214       -2     
- Misses      47442    47445       +3     
  Partials     1621     1621              

Flag	Coverage Δ
backend	57.34% <100.00%> (-0.02%)	⬇️
frontend	20.49% <ø> (ø)
lfx	42.29% <ø> (ø)

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	92.52% <100.00%> (+0.07%)	⬆️

... and 11 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.

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@src/backend/base/pyproject.toml`:
- Line 35: Update the dependency declarations to avoid the pydantic 2.12.5 /
sqlmodel 0.0.22 incompatibility: either bump sqlmodel to >=0.0.32 (the release
that fixes Annotated field handling with Pydantic 2.12+) or constrain pydantic
to a pre-2.12 version (e.g., "pydantic<2.12"); modify the dependency line for
"pydantic" or the "sqlmodel" entry accordingly so the combination used at
runtime is compatible, and run dependency resolution/tests to verify no other
packages break (ensure pydantic-settings >=2.2.0 remains satisfied if you keep
pydantic 2.12.x).

[Cristhianzl]

Detailed Analysis by File

1. src/backend/base/pyproject.toml

Change:

-    "sqlmodel==0.0.22",
-    "pydantic~=2.11.0",
+    "sqlmodel>=0.0.32,<1.0.0",
+    "pydantic~=2.12.5",

Identified Risks

HIGH RISK - SQLModel version range is too broad

• Severity: HIGH
• Type: Production breakage risk
• Description: SQLModel was changed from a pinned version (==0.0.22) to a very broad range (>=0.0.32,<1.0.0). SQLModel is still in pre-release (0.x.x), which means any minor version may contain breaking changes per SemVer for pre-1.0 versions. The range allows installation of future versions like 0.0.40, 0.1.0, 0.2.0, etc., any of which could break the application.
• Impact: A future uv lock or pip install could resolve to a SQLModel version that introduces breaking changes, causing production failures without any code change in Langflow.
• Recommendation: Restrict the range to something more conservative:

  "sqlmodel>=0.0.32,<0.1.0"

  Or use compatible release:

  "sqlmodel~=0.0.32"

  This ensures compatibility with patch versions while protecting against breaking changes in minor versions.

MEDIUM RISK - Pydantic minor version bump

• Severity: MEDIUM
• Type: Dependency incompatibility risk
• Description: Pydantic went from ~=2.11.0 (allows 2.11.x) to ~=2.12.5 (allows 2.12.x). Although the ~= range is conservative, the jump from 2.11 to 2.12 is a minor version bump that may include deprecations or subtle behavioral changes.
• Impact: Transitive dependencies (langchain, langchain-experimental, pydantic-ai, etc.) that rely on specific Pydantic 2.11 behavior may exhibit incompatibilities.
• Existing mitigation: CI passed successfully, which reduces this risk. However, CI tests may not cover all production usage scenarios.

MEDIUM RISK - Propagation to sub-packages

• Severity: MEDIUM
• Type: Dependency conflict risk
• Description: The project has multiple pyproject.toml files:
  • src/backend/base/pyproject.toml: now requires pydantic~=2.12.5
  • src/lfx/pyproject.toml: accepts pydantic>=2.0.0,<3.0.0
  • pyproject.toml (root): does not specify pydantic directly
• Impact: If lfx or another sub-package has dependencies that conflict with Pydantic 2.12, dependency resolution may fail or install unexpected versions.
• Existing mitigation: The uv.lock was updated, which suggests the current resolution works. But conflicts may arise with future dependency updates.

---

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

Change:

 class TransactionReadResponse(TransactionBase):
+    model_config = {"populate_by_name": True, "from_attributes": True}
+
     id: UUID = Field(alias="transaction_id")
     flow_id: UUID

Analysis

POSITIVE - Internal consistency

The sibling class TransactionLogsResponse (line 170) already had exactly the same configuration:

model_config = {"populate_by_name": True, "from_attributes": True}

This makes TransactionReadResponse consistent with its sibling model.

LOW RISK - Mixed config styles

• Severity: LOW
• Type: Style inconsistency / tech debt
• Description: The parent class TransactionBase uses the old-style class Config (line 124-125), while TransactionReadResponse now uses model_config (Pydantic v2 style). Both work, but mixing styles in the same module is inconsistent.
• Impact: Does not cause functional errors, but may confuse developers in the future. In future Pydantic versions, the class Config style may be deprecated.
• Recommendation (nice-to-have): Migrate TransactionBase.Config to model_config as well:

  class TransactionBase(SQLModel):
      model_config = {"arbitrary_types_allowed": True}

LOW RISK - populate_by_name behavior change

• Severity: LOW
• Type: Subtle behavior change
• Description: Adding populate_by_name=True means TransactionReadResponse now accepts both the alias (transaction_id) and the field name (id) to populate the id field. Previously, without this configuration, only the alias was accepted.
• Impact: If there was code that already sent id instead of transaction_id, it would have previously failed silently or with an error; now it will work. This is an "expansive" behavior change (accepts more inputs) that rarely causes problems, but could mask bugs where the wrong name was being used.
• Confirmed current usage: crud.py uses model_validate(t, from_attributes=True), which maps from ORM attributes. TransactionTable has a field id (not transaction_id), so from_attributes=True needs populate_by_name=True to map Table.id -> Response.id (via field name, not alias). This change is necessary and correct for Pydantic 2.12+.

---

Breaking Change Risks

1. SQLModel 0.0.22 -> 0.0.32+ (HIGH)

Changelog between versions (potential breaking changes):

• SQLModel 0.0.32 fixes Annotated field support with Pydantic 2.12+
• Intermediate versions (0.0.23 to 0.0.31) may have API changes in:
  • Field() parameters
  • Session / AsyncSession behavior
  • Query building internals
  • Relationship handling

Langflow areas potentially affected:

• All SQLModel models (not just TransactionTable)
• Queries using select(), where(), etc.
• Alembic migrations (if column metadata generation changed)

2. Pydantic 2.11 -> 2.12 (MEDIUM)

Known changes in Pydantic 2.12:

• Behavior changes in model_validate with from_attributes
• Stricter alias handling (reason for this PR)
• Possible deprecations in validators

Langflow areas potentially affected:

• All Pydantic/SQLModel models in the project
• Custom serializers and validators
• FastAPI integration (response models, request parsing)

3. Cascading effect on dependencies (MEDIUM)

Packages that depend on specific Pydantic/SQLModel versions:

• langchain / langchain-experimental
• pydantic-ai
• pydantic-settings
• fastapi-pagination (reason for this PR)

---

Tests

Coverage of the model.py change

The file src/backend/tests/unit/api/v1/test_transactions.py already contains tests for TransactionReadResponse:

• Line 348: assert isinstance(result, TransactionReadResponse) (single object)
• Line 359: assert all(isinstance(r, TransactionReadResponse) for r in result) (list)

Note: Existing tests validate that model_validate(t, from_attributes=True) works correctly, which covers the model_config change. CI passed, confirming the tests pass with the new versions.

Missing tests (recommendation)

• There is no specific test validating the populate_by_name behavior (accepting both id and transaction_id)
• There is no regression test ensuring the new Pydantic/SQLModel versions do not break other project models (beyond those already covered by CI)

---

Verdict

Category	Score
Security & PII	PASS
DRY	PASS
File structure	PASS
Code quality	PASS
Architecture	PASS
Tests	PASS (with caveats)

Result: APPROVED WITH CAVEATS

Blocking (must be fixed before merge):

• None

Strong recommendations (should be fixed):

1. Restrict SQLModel range from >=0.0.32,<1.0.0 to >=0.0.32,<0.1.0 or ~=0.0.32. The current range is dangerously broad for a pre-1.0 package.
2. Manually verify that Alembic migrations continue to work with SQLModel 0.0.32+, as changes in column metadata generation could cause unintended migrations.

Nice-to-have:
3. Migrate TransactionBase.Config to model_config dict for style consistency within the module.
4. Add a specific test for populate_by_name behavior in TransactionReadResponse.

[Cristhianzl]

lgtm