feat: add deployment failure scenarios test

[pyramation]

Test deployment failure scenarios and rollback behavior

Summary

This PR investigates what happens to the LaunchQL migration database when SQL changes fail during deployment. It adds comprehensive tests for both transaction-based and non-transaction deployment modes using constraint violations as the failure mechanism.

Key findings:

• Transaction mode (default): Automatic rollback of all changes on failure
• Non-transaction mode: Partial deployment where successful changes remain deployed
• Critical discovery: Failure events are NOT logged to launchql_migrate.events table

Implementation details:

• Created focused test suite deploy-failure-scenarios.test.ts with 3 test cases
• Added getMigrationState() method to MigrateTestFixture class that queries timestamp fields for chronological ordering but removes them from snapshots to avoid CI timestamp mismatches
• Updated TestDatabase interface to include the new method
• Added comprehensive analysis document DEPLOYMENT_FAILURE_ANALYSIS.md

Review & Testing Checklist for Human

• Manually test failure scenarios - Run the deployment failure scenarios locally to verify the behavior matches what's documented in the tests and analysis
• Verify chronological ordering - Confirm that getMigrationState() actually returns data ordered by deployed_at/occurred_at timestamps as intended
• Check timestamp removal logic - Ensure the timestamp field removal in getMigrationState() works correctly and doesn't break other functionality
• Test regression safety - Run other tests that use TestDatabase interface to ensure no regressions were introduced
• Validate snapshots - Review the updated snapshots to ensure they accurately reflect expected deployment failure behavior

Recommended test plan: Run yarn test deploy-failure-scenarios.test.ts locally with a fresh PostgreSQL setup, then manually trigger some deployment failures in a test environment to verify the documented behavior.

---

Diagram

%%{ init : { "theme" : "default" }}%%
graph TD
    TestFile["deploy-failure-scenarios.test.ts<br/>New test file"]:::major-edit
    MigrateFixture["MigrateTestFixture.ts<br/>Added getMigrationState()"]:::major-edit
    TestDB["TestDatabase.ts<br/>Updated interface"]:::minor-edit
    Snapshots["__snapshots__/<br/>deploy-failure-scenarios.test.ts.snap<br/>New snapshots"]:::major-edit
    Analysis["DEPLOYMENT_FAILURE_ANALYSIS.md<br/>Documentation"]:::major-edit
    
    TestFile --> MigrateFixture
    TestFile --> TestDB
    TestFile --> Snapshots
    TestFile --> Analysis
    
    MigrateFixture --> TestDB
    
    subgraph Legend
        L1[Major Edit]:::major-edit
        L2[Minor Edit]:::minor-edit
        L3[Context/No Edit]:::context
    end

classDef major-edit fill:#90EE90
classDef minor-edit fill:#87CEEB
classDef context fill:#FFFFFF

Loading

Notes

• The getMigrationState() method was moved from the test file to MigrateTestFixture per user request to keep test code clean and minimal
• Constraint violations were chosen as the failure mechanism because they still parse but fail at execution time
• The analysis document provides detailed snapshots of database state for both failure modes
• All CI checks are passing, but manual verification of the failure scenarios is recommended

Session details: Requested by Dan Lynch (@pyramation) - Link to Devin run

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment and CI monitoring