feat: allow alembic startup when db is at newer schema by jordanrfrazier · Pull Request #10878 · langflow-ai/langflow

jordanrfrazier · 2025-12-04T01:38:58Z

Allows langflow to start up and bypass alembic migration check when the database is at a newer schema than the source. This allows rollback of Langflow versioning for any reason without downgrading the database and potentially losing user data.

With the combination of migration guardrails assuring backwards-compatibility, this allows a previous langflow version to function normally on a newer database schema.

Note that the "is_db_ahead" assumes that a revision that cannot be found == ahead. There may be branching or corrupted states that are false positives.

Summary by CodeRabbit

Bug Fixes
- Enhanced database migration error detection to identify and gracefully handle schema version conflicts
- Improved application startup when database schema is ahead of or misaligned with application code
- Better error handling and logging during database initialization failures
Tests
- Added comprehensive unit tests for migration compatibility and rollback scenarios

_{✏️ Tip: You can customize this high-level summary in your review settings.}

Allow langflow to start up when database is at newer migration

coderabbitai · 2025-12-04T01:39:18Z

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

This change adds database migration state detection to identify when the database schema is ahead of or behind the code migrations. It enhances error handling in the migration flow by distinguishing between specific Alembic error conditions and deciding whether to allow startup or propagate errors. Includes comprehensive unit tests.

Changes

Cohort / File(s)	Summary
Migration state detection logic `src/backend/base/langflow/services/database/service.py`	Adds `_check_if_database_ahead()` and `_handle_database_ahead()` methods to analyze Alembic error messages, extract revisions, and determine schema state. Integrates these checks into `_run_migrations()` to conditionally allow startup or retry based on database-ahead detection. Expands Alembic imports to include `script` for revision lookups.
Error handling enhancement `src/backend/base/langflow/services/database/utils.py`	Refactors `initialize_database()` CommandError handling into three explicit branches: "Can't locate revision" → log info and return; "overlaps with other requested revisions" → log warning, drop alembic_version table, retry, and return; other errors → re-raise. Centralizes error message extraction.
Alembic migration tests `src/backend/tests/unit/services/database/test_alembic_rollback.py`	Adds comprehensive unit test module covering `_check_if_database_ahead()`, `_handle_database_ahead()`, and `_run_migrations()` under varied scenarios (DB ahead, DB behind, upgrade failures, overlapping revisions). Validates revision extraction from Alembic error messages and control flow decisions via mocks and patches.

Sequence Diagram(s)

sequenceDiagram
    participant App as Application
    participant DS as DatabaseService
    participant Alembic
    participant DB as Database
    
    App->>DS: _run_migrations()
    DS->>Alembic: Check migration status
    
    alt Migration check fails
        Alembic-->>DS: CommandError
        DS->>DS: _check_if_database_ahead()
        alt Database is ahead
            DS->>DS: Log warning: DB ahead of code
            DS-->>App: Return (allow startup)
        else Database not ahead
            DS->>Alembic: Attempt upgrade
            alt Upgrade succeeds
                Alembic->>DB: Apply migrations
                DB-->>Alembic: OK
                Alembic-->>DS: Success
                DS-->>App: Return (startup)
            else Upgrade fails
                Alembic-->>DS: CommandError
                DS->>DS: _check_if_database_ahead() (retry)
                alt Database is ahead (confirmed)
                    DS->>DS: Log warning: DB ahead of code
                    DS-->>App: Return (allow startup)
                else Still not ahead
                    DS-->>App: Re-raise error
                end
            end
        end
    else Migration check succeeds
        Alembic-->>DS: OK
        DS-->>App: Continue startup
    end

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~30 minutes

Areas requiring extra attention:

Alembic error message parsing logic in _check_if_database_ahead() and _handle_database_ahead() — verify regex/string matching handles edge cases
Integration points in _run_migrations() where new ahead-checks are inserted — ensure control flow doesn't inadvertently suppress legitimate errors
Test coverage for revision extraction with special characters and quote variants — validate parsing robustness

Possibly related PRs

feat(database): add noop mode with config flag and update related tests #9054 — Modifies the same DatabaseService class with additional Alembic migration handling in _run_migrations() and session management changes.

Suggested labels

enhancement, size:L

Suggested reviewers

rjordanfrazier

Pre-merge checks and finishing touches

❌ Failed checks (1 warning, 1 inconclusive)

Check name	Status	Explanation	Resolution
Test File Naming And Structure	⚠️ Warning	Test file mentioned in PR summary (src/backend/tests/unit/services/database/test_alembic_rollback.py) does not exist in repository; directory structure is incomplete.	Create the missing test file with proper pytest structure, descriptive test function names, fixtures, parametrized tests for edge cases, and comprehensive coverage of new methods _check_if_database_ahead and _handle_database_ahead including mocking and error validation.
Excessive Mock Usage Warning	❓ Inconclusive	Test file test_alembic_rollback.py does not exist in the repository. Cannot assess mock usage patterns without reviewing actual test code.	Locate and provide the test file to evaluate mock usage, mock types, and whether real test doubles could replace mocks to improve test design.

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: allowing Alembic to start when the database schema is newer than the code, which is the core objective of this PR.
Docstring Coverage	✅ Passed	Docstring coverage is 86.96% which is sufficient. The required threshold is 80.00%.
Test Coverage For New Implementations	✅ Passed	PR includes comprehensive test file with 15 well-structured test functions thoroughly covering new database migration functionality across multiple scenarios and edge cases.
Test Quality And Coverage	✅ Passed	The test suite demonstrates solid quality with 18 distinct test scenarios, 87 mock usages, and 43 assertions covering unit, integration, and async scenarios. All new methods are tested with positive and negative cases including edge scenarios. Error handling is validated appropriately using mocks.

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

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

github-actions · 2025-12-04T01:46:06Z

Frontend Unit Test Coverage Report

Coverage Summary

Lines	Statements	Branches	Functions
	15.43% (4244/27499)	8.61% (1811/21013)	9.69% (587/6057)

Unit Test Results

Tests	Skipped	Failures	Errors	Time
1671	0 💤	0 ❌	0 🔥	21.349s ⏱️

codecov · 2025-12-04T01:46:22Z

Codecov Report

❌ Patch coverage is 95.65217% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 32.61%. Comparing base (f5a50c1) to head (d63d4aa).
⚠️ Report is 436 commits behind head on main.

Files with missing lines	Patch %	Lines
...backend/base/langflow/services/database/service.py	94.28%	2 Missing ⚠️

❌ Your project status has failed because the head coverage (39.96%) 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   #10878      +/-   ##
==========================================
+ Coverage   32.55%   32.61%   +0.05%     
==========================================
  Files        1370     1370              
  Lines       63544    63581      +37     
  Branches     9394     9394              
==========================================
+ Hits        20685    20735      +50     
+ Misses      41820    41807      -13     
  Partials     1039     1039

Flag	Coverage Δ
backend	`51.77% <95.65%> (+0.18%)`	⬆️
frontend	`14.28% <ø> (ø)`
lfx	`39.96% <ø> (ø)`

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

Files with missing lines	Coverage Δ
...c/backend/base/langflow/services/database/utils.py	`72.30% <100.00%> (+13.97%)`	⬆️
...backend/base/langflow/services/database/service.py	`67.97% <94.28%> (+7.48%)`	⬆️

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

🧹 Nitpick comments (2)

src/backend/tests/unit/services/database/test_alembic_rollback.py (2)
299-341: Verify mock session context manager setup.

The mock session setup for the async context manager pattern (lines 318-321) looks correct, but the test should verify that session.exec was called with the DROP TABLE statement.

Consider adding an assertion to verify the DROP TABLE was executed:
             # Verify run_migrations was called twice
             assert mock_db_service.run_migrations.call_count == 2
+            
+            # Verify DROP TABLE was executed
+            mock_session.exec.assert_called_once()
+            call_args = mock_session.exec.call_args[0][0]
+            assert "DROP TABLE alembic_version" in str(call_args)
398-398: Remove trailing debug comment.

This appears to be a signature or debug comment that should be removed before merging.
-# Made with Bob

📜 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 f5a50c1 and 2b35f71.

⛔ Files ignored due to path filters (1)

uv.lock is excluded by !**/*.lock

📒 Files selected for processing (3)

src/backend/base/langflow/services/database/service.py (3 hunks)
src/backend/base/langflow/services/database/utils.py (1 hunks)
src/backend/tests/unit/services/database/test_alembic_rollback.py (1 hunks)

🧰 Additional context used

📓 Path-based instructions (3)

src/backend/**/*.py

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

src/backend/**/*.py: Use FastAPI async patterns with await for async operations in component execution methods
Use asyncio.create_task() for background tasks and implement proper cleanup with try/except for asyncio.CancelledError
Use queue.put_nowait() for non-blocking queue operations and asyncio.wait_for() with timeouts for controlled get operations

Files:

src/backend/tests/unit/services/database/test_alembic_rollback.py
src/backend/base/langflow/services/database/service.py
src/backend/base/langflow/services/database/utils.py

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

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

src/backend/tests/**/*.py: Place backend unit tests in src/backend/tests/ directory, component tests in src/backend/tests/unit/components/ organized by component subdirectory, and integration tests accessible via make integration_tests
Use same filename as component with appropriate test prefix/suffix (e.g., my_component.py → test_my_component.py)
Use the client fixture (FastAPI Test Client) defined in src/backend/tests/conftest.py for API tests; it provides an async httpx.AsyncClient with automatic in-memory SQLite database and mocked environment variables. Skip client creation by marking test with @pytest.mark.noclient
Inherit from the correct ComponentTestBase family class located in src/backend/tests/base.py based on API access needs: ComponentTestBase (no API), ComponentTestBaseWithClient (needs API), or ComponentTestBaseWithoutClient (pure logic). Provide three required fixtures: component_class, default_kwargs, and file_names_mapping
Create comprehensive unit tests for all new backend components. If unit tests are incomplete, create a corresponding Markdown file documenting manual testing steps and expected outcomes
Test both sync and async code paths, mock external dependencies appropriately, test error handling and edge cases, validate input/output behavior, and test component initialization and configuration
Use @pytest.mark.asyncio decorator for async component tests and ensure async methods are properly awaited
Test background tasks using asyncio.create_task() and verify completion with asyncio.wait_for() with appropriate timeout constraints
Test queue operations using non-blocking queue.put_nowait() and asyncio.wait_for(queue.get(), timeout=...) to verify queue processing without blocking
Use @pytest.mark.no_blockbuster marker to skip the blockbuster plugin in specific tests
For database tests that may fail in batch runs, run them sequentially using uv run pytest src/backend/tests/unit/test_database.py r...

Files:

src/backend/tests/unit/services/database/test_alembic_rollback.py

**/test_*.py

📄 CodeRabbit inference engine (Custom checks)

**/test_*.py: Review test files for excessive use of mocks that may indicate poor test design - 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, and suggest using real objects or test doubles when mocks become excessive
Ensure mocks are used appropriately for external dependencies only, not for core logic
Backend test files should follow the naming convention test_*.py with proper pytest structure
Test files should have descriptive test function names that explain what is being tested
Tests should be organized logically with proper setup and teardown
Consider including edge cases and error conditions for comprehensive test coverage
Verify tests cover both positive and negative scenarios where appropriate
For async functions in backend tests, ensure proper async testing patterns are used with pytest
For API endpoints, verify both success and error response testing

Files:

src/backend/tests/unit/services/database/test_alembic_rollback.py

🧠 Learnings (8)