Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #3934 +/- ##
=======================================
Coverage 88.74% 88.74%
=======================================
Files 25 25
Lines 2425 2425
Branches 610 613 +3
=======================================
Hits 2152 2152
Misses 271 271
Partials 2 2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Note: This review was produced by Claude (Opus) and vetted by @alco.
Correctness Issues
1. "After restart" test coverage gap (shape_cache_test.exs)
The @describetag skip: not ShapeStatus.ShapeDb.persistent?() on the "after restart" describe block skips the entire block when InMemory is active. But the test "can recover consumers after restart" was specifically reworked to use the new restart_shape_cache_only/2 helper, which keeps the InMemory shape db alive across the restart. That test should be exercisable with InMemory — the whole point of the helper change is to avoid needing persistence. As written, it will never run because the describe-level skip tag blankets it.
Either that test should be moved out of the describe block, or it should get @tag skip: false to override the describe-level tag.
2. Dead SQLite config in config.ex
config.ex still computes defaults from ShapeDb.Sqlite.Connection.default!(:synchronous) and ShapeDb.Sqlite.Connection.default!(:cache_size). These flow into shape_db_opts in the main opts keyword, but MonitoredCoreSupervisor now does Keyword.take(opts, [:stack_id]) for the InMemory supervisor — shape_db_opts is never extracted. These config entries are dead code. If the SQLite module ever fails to compile (e.g., exqlite dep removed), these will break config.ex at compile time.
3. persistent?/0 on Sqlite.Supervisor is orphaned
persistent?/0 was added to both Sqlite (the main module) and Sqlite.Supervisor. The delegation from ShapeDb goes to @implementation which is InMemory, so ShapeDb.persistent?/0 returns false. Nobody calls Sqlite.Supervisor.persistent?/0. It's unclear why it's on the Supervisor rather than only on the Sqlite module.
Things that look correct
- The ETS table layout and key design (
{:shape, handle},{:comparable, comparable_hash},:count) is clean and avoids key collisions. comparable_to_hash/1matches the hashing logic inShapeDb.Sqlite.Query, so shapes are identified consistently across implementations.handle_for_shape_critical/2correctly aliases tohandle_for_shape/2since ETS reads are always consistent.validate_existing_shapes/1correctly removes incomplete shapes and adjusts the counter.- All SQLite module renames under
ShapeDb.Sqlitelook mechanically correct — module names, aliases, and function references are all updated consistently. - The InMemory test suite is thorough and mirrors the ShapeDb test structure well.
- The
restart_shape_cache_only/stop_shape_cache_and_dbsplit inshape_cache_test.exsis a good factoring.
3fb82e9 to
694212e
Compare
✅ Deploy Preview for electric-next ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
1f48610 to
52f056f
Compare
|
Found 1 test failure on Blacksmith runners: Failure
|
3f825e6 to
ee4806c
Compare
also validate the ast before calling the protobuf_to_query to catch and log the problem
ee4806c to
ff50c2a
Compare
No description provided.