cre-5718: one-shot readiness effect with a regression test

[mchain0]

one-shot readiness effect with a regression test

all details in the JIRA issue linked below

cre-5718

---

A note for the reviewer:

The fix extends the s.mu critical section to include Aggregate().

Before (original):

s.mu.Lock()
  Insert + Ready(once=true)    // fast: map ops + timestamp scan
s.mu.Unlock()                  // ← lock released here
Aggregate(...)                 // CPU-bound: byte compare or SHA256 hashing
callback <- response           // channel send

After (fix):

s.mu.Lock()
  Insert + Ready(once=false)   // fast: map ops + timestamp scan
  Aggregate(...)               // CPU-bound — NOW UNDER LOCK
  MarkDelivered                // trivial
s.mu.Unlock()                  // ← lock released here
callback <- response           // channel send (still outside lock)

As far as I checked the latency it's marginally worse, but pls think about cases where this could go south. There is an option to make it non-blocking, but it would make this code even less readable.

[github-actions]

👋 mchain0, thanks for creating this pull request!

To help reviewers, please consider creating future PRs as drafts first. This allows you to self-review and make any final changes before notifying the team.

Once you're ready, you can mark it as "Ready for review" to request feedback. Thanks!

[github-actions]

✅ No conflicts with other open PRs targeting develop

[github-actions]

I see you updated files related to core. Please run make gocs in the root directory to add a changeset as well as in the text include at least one of the following tags:

• #added For any new functionality added.
• #breaking_change For any functionality that requires manual action for the node to boot.
• #bugfix For bug fixes.
• #changed For any change to the existing functionality.
• #db_update For any feature that introduces updates to database schema.
• #deprecation_notice For any upcoming deprecation functionality.
• #internal For changesets that need to be excluded from the final changelog.
• #nops For any feature that is NOP facing and needs to be in the official Release Notes for the release.
• #removed For any functionality/config that is removed.
• #updated For any functionality that is updated.
• #wip For any change that is not ready yet and external communication about it should be held off till it is feature complete.

[cl-sonarqube-production]

Quality Gate failed

Failed conditions
C Reliability Rating on New Code (required ≥ A)
4.67% Technical Debt Ratio on New Code (required ≤ 4%)

See analysis details on SonarQube

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[trunk-io]

   

View Full Report ↗︎ ⋅ Docs

[cedric-cordenier]

@mchain0 This is indeed a brain twister 😬

Am I missing something, or would it be enough to basically have the same code as before, but just add MarkDelivered to line 385? In other words, we're quite happy for Ready() to return true multiple times as long as we fail to aggregate (so that each subsequent message gives us a chance to re-aggregate); however once we have successfully aggregated, we should consume the one-shot.

[mchain0]

ok, I applied this and rerun the test - it seems to be ok-ish ...

two concerns:

• Receive is single-thread, so as long as this concurrency stays like it - we're safe
• TestMessageCache_InsertReady test fails after the change, it expects Ready(once=true) to be one-shot by itself, so I would have to change this test - no idea what's the impact of changing this behavior

also this would would mean Ready never sets wasReady only MarkDelivered does - that's cleaner