Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #3934 +/- ##
==========================================
+ Coverage 87.21% 88.77% +1.56%
==========================================
Files 25 25
Lines 2394 2415 +21
Branches 599 607 +8
==========================================
+ Hits 2088 2144 +56
+ Misses 304 269 -35
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:
|
|
Found 1 test failure on Blacksmith runners: Failure
|
alco
left a comment
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.
342ee12 to
3fb82e9
Compare
No description provided.