Skip to content

test(e2e): scenario 5 — v1.4 migration roundtrip (#334 step 3) - #366

Merged
robotrocketscience merged 2 commits into
mainfrom
test/issue-334-step3-migration-scenario
May 3, 2026
Merged

test(e2e): scenario 5 — v1.4 migration roundtrip (#334 step 3)#366
robotrocketscience merged 2 commits into
mainfrom
test/issue-334-step3-migration-scenario

Conversation

@yoshi280

@yoshi280 yoshi280 commented May 3, 2026

Copy link
Copy Markdown
Collaborator

Summary

Step 3 of #334 rollout: lands scenario #5 (v1.4 → current migration), advancing the umbrella's seed-scenario gate from 3/4 to 4/4.

  • Fixture infratests/e2e/fixtures/v14-snapshot.db is a 124KB SQLite snapshot built from a clean aelfrice==1.4.0 install with three seeded aelf lock statements (quokka/aardvark/wibble). build-v14-snapshot.sh regenerates it idempotently from the v1.4.0 PyPI release. .gitignore unignores tests/e2e/fixtures/*.db so the binary fixture checks in — keeps the e2e job offline.
  • tests/e2e/test_migration_v14_to_current.py — 3 tests:
    • test_v14_snapshot_seeds_are_searchable_after_migrationaelf search <token> returns each seeded statement; pre-asserts the fixture genuinely lacks the post-v1.4 tables so the test doesn't degrade silently.
    • test_v14_migration_grows_tables_and_preserves_belief_rows — the migration adds belief_corroborations + ingest_log + belief_versions, and the original belief rows survive verbatim.
    • test_search_after_migration_returns_seeded_belief — same shape but goes through the suite's aelf_run fixture (env-overlay path).

The bug class: unit suites that test fresh-init DBs are structurally blind to a migration that drops or corrupts existing rows on a real on-disk shape. This test fails when that drift happens.

Test plan

  • uv run pytest tests/e2e/ -q — all 9 cases pass locally (6 from steps 1-2 + 3 new)
  • uvx ruff check tests/e2e/test_migration_v14_to_current.py — clean
  • Discretion check — clean (only aelf binary refs, public API)
  • Fixture builder verified to regenerate the snapshot deterministically against aelfrice==1.4.0
  • CI e2e workflow runs on this PR via the e2e label opt-in (reviewer adds label)
  • At least 2 of {uv-tool, pipx, venv-pip} install methods green

Closes #334's seed-gate (4/4 scenarios). Failure-surfacing job + docs/testing-strategy.md remain (separate follow-up PRs).

Summary by Sourcery

Add an end-to-end migration scenario ensuring v1.4 SQLite databases upgrade correctly to the current schema without losing data.

Tests:

  • Add e2e tests verifying search and locked-belief behavior against a v1.4 snapshot before and after migration, including coverage via the shared aelf_run fixture.

Chores:

  • Introduce a reproducible script to build a v1.4 SQLite snapshot fixture and check in the generated database by adjusting .gitignore.

Summary by CodeRabbit

  • Tests

    • Added end-to-end tests for database migrations between version 1.4 and current.
    • Tests exercise search functionality and database structure changes after migration.
    • Added automated fixture infrastructure for reproducible migration testing.
  • Chores

    • Updated test fixture configuration to track database snapshots.

The snapshot is built from the v1.4.0 PyPI release seeded with three
distinctive lock statements (quokka/aardvark/wibble). build-v14-snapshot.sh
regenerates the fixture deterministically from a fresh aelfrice==1.4.0
install — re-run when the v1.4 install path changes or to verify
reproducibility. Unignore tests/e2e/fixtures/*.db so the binary fixture
checks in (avoids requiring PyPI access at test time).
Loads the v1.4 fixture DB through the installed aelf binary and asserts:

  1. aelf search returns each seeded statement's distinctive token
     after the implicit migration on first connect.
  2. The migration adds the post-v1.4 tables that current code
     requires (belief_corroborations, ingest_log, belief_versions).
  3. The original belief rows are preserved verbatim through the
     additive schema changes.

Catches the class of regression where unit tests stay green against
fresh-init DBs but a migration silently drops or corrupts existing
rows on real on-disk shapes. Advances #334 acceptance gate from
3/4 to 4/4 seed scenarios.
@sourcery-ai

sourcery-ai Bot commented May 3, 2026

Copy link
Copy Markdown

Reviewer's Guide

Adds an end-to-end migration scenario that validates upgrading a real v1.4 SQLite database to the current schema, using a checked-in binary fixture and a deterministic builder script, and verifies search behavior and table/row integrity via subprocess-invoked aelf binaries.

File-Level Changes

Change Details Files
Introduce e2e tests that exercise migration from a real v1.4 SQLite snapshot to the current schema via the installed aelf binary.
  • Add helper functions to inspect SQLite table names and belief statements from a read-only connection.
  • Add a fixture that provides a per-test writable copy of the v1.4 snapshot, skipping tests if the fixture is missing.
  • Add a test that asserts the v1.4 snapshot lacks post-v1.4 tables and that aelf search can find each seeded statement after migration.
  • Add a test that triggers migration via aelf locked, then asserts required new tables exist and seeded belief rows are preserved exactly.
  • Add an e2e test using the existing aelf_run fixture to ensure the migration works under the suite’s standard env-overlay path.
tests/e2e/test_migration_v14_to_current.py
Add deterministic fixture-generation script and check in the resulting v1.4 SQLite snapshot for offline e2e testing.
  • Add a Bash script that creates an isolated virtualenv, installs aelfrice==1.4.0, seeds three specific aelf lock statements, and writes v14-snapshot.db.
  • Ensure the script is idempotent, self-locating, and cleans up its temporary build directory.
  • Update ignore rules so .db fixtures under tests/e2e/fixtures/ are tracked in version control.
tests/e2e/fixtures/build-v14-snapshot.sh
.gitignore

Assessment against linked issues

Issue Objective Addressed Explanation
#334 Introduce an e2e CI workflow/job in .github/workflows/ that runs the end-to-end suite on every push to main and on PRs labeled e2e, with failure surfacing via the e2e status check and attn:e2e-failure issue/label behavior. The PR only adds an end-to-end test file (test_migration_v14_to_current.py) and a fixture builder script. It does not modify or add any GitHub Actions workflows, nor any failure-surfacing automation.
#334 Implement the initial end-to-end test suite and fixtures, including at least scenarios 1, 2, 3, and 5, with the required SQLite fixtures (e.g., v1.4 snapshot) and install-method matrix support. The PR implements only scenario #5 (v1.4 → current migration) via tests/e2e/test_migration_v14_to_current.py and adds the build-v14-snapshot.sh script and corresponding fixture. Scenarios 1, 2, and 3, as well as the install-method matrix configuration, are not added or modified in this PR.
#334 Add docs/testing-strategy.md documenting the unit / integration / E2E testing split and how new tests should be classified. The PR does not add or modify any documentation files; specifically, there is no docs/testing-strategy.md introduced or updated.

Possibly linked issues


Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

@yoshi280 yoshi280 added attn:review Needs review (PR open, awaiting reviewer) e2e Trigger E2E workflow on this PR labels May 3, 2026
@coderabbitai

coderabbitai Bot commented May 3, 2026

Copy link
Copy Markdown

Caution

Review failed

Pull request was closed or merged during review

📝 Walkthrough

Walkthrough

The PR adds support for end-to-end testing of v1.4→current database migrations: a fixture-building script that creates a v1.4 snapshot database from a clean install, a .gitignore exception to track the fixture, and comprehensive E2E tests validating search functionality and schema migration correctness.

Changes

v1.4 Migration E2E Testing

Layer / File(s) Summary
Fixture Tracking
.gitignore
Negation rule added to allow tests/e2e/fixtures/*.db files to be committed while other *.db files remain ignored.
Fixture Build Script
tests/e2e/fixtures/build-v14-snapshot.sh
Bash script creates a v1.4 snapshot database by installing aelfrice==1.4.0 in an isolated venv, seeding three predetermined aelf lock commands into a fresh SQLite DB, and copying the result to v14-snapshot.db.
Migration Test Suite
tests/e2e/test_migration_v14_to_current.py
E2E test module validates v1.4→current migrations using the snapshot fixture: helpers inspect read-only SQLite DBs, a v14_db fixture copies the snapshot per-test, and three test functions verify search still finds seeded content after migration, confirm required post-migration tables are created while preserving original belief rows, and exercise migration via the aelf_run fixture variant with the snapshot DB.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

Suggested labels

author-Setr, e2e

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 71.43% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly identifies the main change: adding e2e migration tests for v1.4 to current scenario (step 3 of #334), which aligns with the primary objective.
Description check ✅ Passed The description comprehensively covers summary, linked issue (#334), type of change (test), test plan results, and notes for reviewer following the template structure.
Linked Issues check ✅ Passed All coding requirements from #334 for scenario 5 are implemented: v14-snapshot.db fixture, deterministic builder script, .gitignore exception, and three e2e tests validating migration correctness and searchability.
Out of Scope Changes check ✅ Passed All changes directly support scenario #5 (v1.4 migration) implementation: fixture creation, build script, tests, and .gitignore updates. No unrelated modifications detected.

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

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch test/issue-334-step3-migration-scenario

Tip

💬 Introducing Slack Agent: The best way for teams to turn conversations into code.

Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.

  • Generate code and open pull requests
  • Plan features and break down work
  • Investigate incidents and troubleshoot customer tickets together
  • Automate recurring tasks and respond to alerts with triggers
  • Summarize progress and report instantly

Built for teams:

  • Shared memory across your entire org—no repeating context
  • Per-thread sandboxes to safely plan and execute work
  • Governance built-in—scoped access, auditability, and budget controls

One agent for your entire SDLC. Right inside Slack.

👉 Get your free trial and get 200 agent minutes per Slack user (a $50 value).


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
Review rate limit: 0/1 reviews remaining, refill in 60 minutes.

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

@sourcery-ai sourcery-ai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey - I've left some high level feedback:

  • The subprocess calls build a minimal env with only AELFRICE_DB and PATH, which discards the rest of the parent environment; consider starting from os.environ.copy() and overlaying AELFRICE_DB/PATH so the tests don’t accidentally depend on missing variables on some systems.
  • The repeated FIXTURE.exists() checks and skip messages could be centralized into a small helper or fixture so the regeneration instructions and path logic stay single-sourced and easier to update if the fixture moves.
Prompt for AI Agents
Please address the comments from this code review:

## Overall Comments
- The subprocess calls build a minimal `env` with only `AELFRICE_DB` and `PATH`, which discards the rest of the parent environment; consider starting from `os.environ.copy()` and overlaying `AELFRICE_DB`/`PATH` so the tests don’t accidentally depend on missing variables on some systems.
- The repeated `FIXTURE.exists()` checks and skip messages could be centralized into a small helper or fixture so the regeneration instructions and path logic stay single-sourced and easier to update if the fixture moves.

Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

@yoshi280

yoshi280 commented May 3, 2026

Copy link
Copy Markdown
Collaborator Author

[claim:review:Gylf:2026-05-03T03:40:03Z]

@robotrocketscience
robotrocketscience merged commit 617d822 into main May 3, 2026
25 of 32 checks passed
@robotrocketscience
robotrocketscience deleted the test/issue-334-step3-migration-scenario branch May 3, 2026 03:40
@yoshi280

yoshi280 commented May 3, 2026

Copy link
Copy Markdown
Collaborator Author

[release:review:Gylf:2026-05-03T03:40:58Z]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

attn:review Needs review (PR open, awaiting reviewer) e2e Trigger E2E workflow on this PR

Projects

None yet

Development

Successfully merging this pull request may close these issues.

ci: end-to-end integration test job — catch system-level regressions per-merge

2 participants