Conversation
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ✅ Deployment successful! View logs |
commonware-mcp | b8b8cdb | May 22 2026, 09:30 PM |
Deploying monorepo with
|
| Latest commit: |
b8b8cdb
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://68b488d3.monorepo-eu0.pages.dev |
| Branch Preview URL: | https://cl-glue.monorepo-eu0.pages.dev |
clabby
force-pushed
the
cl/glue
branch
2 times, most recently
from
ec309a7 to
96b2c10
Compare
clabby
force-pushed
the
cl/glue
branch
3 times, most recently
from
6684c46 to
2e52801
Compare
clabby
force-pushed
the
cl/glue
branch
7 times, most recently
from
70184bd to
70446b7
Compare
clabby
force-pushed
the
cl/glue
branch
3 times, most recently
from
110ccdb to
490d076
Compare
clabby
force-pushed
the
cl/glue
branch
2 times, most recently
from
93f92d9 to
dde00be
Compare
clabby
force-pushed
the
cl/glue
branch
3 times, most recently
from
2ea214b to
88f6634
Compare
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
clabby
force-pushed
the
cl/glue
branch
2 times, most recently
from
c249898 to
2882334
Compare
Benchmark resultsTip ✅ PASSED: No benchmark exceeded the regression threshold. Benchmark comparison table
Baseline commit(s): |
| .unwrap_or(Duration::ZERO); | ||
| if time > elapsed { | ||
| ctx.sleep(time - elapsed).await; | ||
| } |
There was a problem hiding this comment.
Schedule events silently misfire when added out of order
Low Severity
Schedule is documented as "A time-ordered sequence of simulation actions" but neither at() nor run_action_scheduler sort or validate chronological order. The scheduler computes elapsed time from start, then only sleeps if time > elapsed. If a user adds events out of order (e.g., 5s then 2s), the second event executes immediately after the first instead of at its intended time, silently producing incorrect simulation behavior. A debug_assert! in at() that the new time is >= the last event's time would catch this.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit 31e8c9a. Configure here.
| .values() | ||
| .filter(|v| **v >= required_view) | ||
| .count() | ||
| >= total |
There was a problem hiding this comment.
Exit counts crashed validators
Medium Severity
The simulation passes target_count as the number of currently active validators, but MinimumFinalizations uses ProgressTracker::all_reached, which counts any validator that ever reported a finalization—including crashed nodes whose handles were removed. A run can end while still-active validators have not reached the required view.
Additional Locations (2)
Reviewed by Cursor Bugbot for commit d28e265. Configure here.
| // the actor sees a contiguous finalized stream after target | ||
| // selection. Every later finalized block can then become both a | ||
| // sync target update and an acknowledgement toward handoff. | ||
| marshal.set_floor(finalization.clone()); |
There was a problem hiding this comment.
to confirm, you provide marshal genesis on init rather than this directly?
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
There are 3 total unresolved issues (including 2 from previous reviews).
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 7db57b4. Configure here.
| } | ||
|
|
||
| syncing.last_acknowledged = height; | ||
| acknowledgement.acknowledge(); |
There was a problem hiding this comment.
Acknowledged blocks lost between sync completion and transition
High Severity
In handle_syncing_finalized, when target_sender.send(update) fails (because the sync engine finished and dropped the ring receiver), the code still advances last_acknowledged and calls acknowledgement.acknowledge(). This creates a gap: blocks between the sync engine's final height and last_acknowledged are acknowledged to marshal (so marshal won't redeliver them) but never incorporated into the databases. When try_enter_processing transitions to Processing mode, the processor's last_processed is the sync engine's final height, but the next block marshal delivers is above last_acknowledged. The intervening blocks were effectively swallowed, causing a "finalize replay state root must match block commitments" panic on the first post-transition finalization.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit 7db57b4. Configure here.
There was a problem hiding this comment.
This is correct. Old code handled this by buffering acks until sync was done to facilitate a graceful handoff to the Processing mode, was working on a tweak for this but ran out of time.
Codecov Report❌ Patch coverage is @@ Coverage Diff @@
## main #3381 +/- ##
==========================================
- Coverage 95.77% 95.06% -0.71%
==========================================
Files 486 513 +27
Lines 201251 208260 +7009
Branches 4876 5103 +227
==========================================
+ Hits 192754 197992 +5238
- Misses 6862 8535 +1673
- Partials 1635 1733 +98
... and 28 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
| publish = true | ||
| version.workspace = true | ||
| license.workspace = true | ||
| description = "Bootstrap applications with commonware primitive compositions." |
There was a problem hiding this comment.
nit: "Construct stateful applications with efficient synchronization."
2 participants
Overview
Adds the
commonware-gluecrate, which will house opinionated compositions of commonware primitives.The first module within
glueisstateful, which is a composition ofcommonware-storage's QMDBs andcommonware-consensus'Application.In the future, this crate also may house constructs like application-managed DKGs (a. la.
reshare).Depends On
qmdb::keylessCommit operation #3624qmdb::immutableCommit operation #3588qmdb::keyless,qmdb::immutable, persisted merkle implementations #3650BatchVerifier#3749commonware-gluemarshal changes #3764