Track user's participated blockcount #306

Merged
parabitdev merged 8 commits from parabit/track-user-participated-blocks into master 2025-12-11 22:09:35 +00:00
parabitdev commented 2025-12-11 19:32:40 +00:00 (Migrated from github.com)
  • closes #302
    • update account migration to recalculate participated blocks
    • update share sync to increment blockcount
    • come up with plan to handle deduplication
    • add tests
- [x] closes #302 - [x] update account migration to recalculate participated blocks - [x] update share sync to increment blockcount - [x] come up with plan to handle deduplication - [x] add tests
parabitdev (Migrated from github.com) reviewed 2025-12-11 20:45:27 +00:00
@ -387,3 +354,1 @@
ELSE accounts.lnurl_updated_at
END,
updated_at = NOW();
INSERT INTO accounts (username, lnurl, past_lnurls, total_diff, created_at, updated_at)
parabitdev (Migrated from github.com) commented 2025-12-11 20:45:27 +00:00

Only the final part (referencing account_metadata) is changed, rest just had indentation fixed.

Only the final part (referencing account_metadata) is changed, rest just had indentation fixed.
parabitdev (Migrated from github.com) reviewed 2025-12-11 20:46:53 +00:00
@ -804,0 +802,4 @@
if share.result == Some(true) {
if let Some(diff) = share.diff {
entry.total_diff += diff;
}
parabitdev (Migrated from github.com) commented 2025-12-11 20:46:53 +00:00

Typically, this will only be a single block, but there is an edge-case (one of the two causes of duplicate counts) where we send records from more than one block.

Typically, this will only be a single block, but there is an edge-case (one of the two causes of duplicate counts) where we send records from more than one block.
parabitdev (Migrated from github.com) reviewed 2025-12-11 21:57:45 +00:00
parabitdev (Migrated from github.com) commented 2025-12-11 21:57:45 +00:00

Two is better as we get an explicit per-query error. If we were performance constrained then this may be an area for some improvement.

Two is better as we get an explicit per-query error. If we were performance constrained then this may be an area for some improvement.
parabitdev (Migrated from github.com) reviewed 2025-12-11 22:00:14 +00:00
parabitdev (Migrated from github.com) commented 2025-12-11 22:00:14 +00:00

The sending side sends blocks in order. It is possible for blocks to come in out of order, but would require a server to fall behing on sync while a reorg was happening for it to impact this. The effect would be that all users would be missing one point (which can be corrected by running the migration/refresh).

The sending side sends blocks in order. It is possible for blocks to come in out of order, but would require a server to fall behing on sync while a reorg was happening for it to impact this. The effect would be that all users would be missing one point (which can be corrected by running the migration/refresh).
parabitdev (Migrated from github.com) reviewed 2025-12-11 22:06:07 +00:00
@ -844,6 +849,39 @@ impl Server {
.execute(&mut *tx)
parabitdev (Migrated from github.com) commented 2025-12-11 22:06:07 +00:00

Yes we can 😂

Yes we can :joy:
Sign in to join this conversation.
No description provided.