feat(ui): 15-minute aggregation collapses repeated subnet-activity rows - #8466
Merged
Conversation
Contributor
|
Important 🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨 ⏳ LoopOver is waiting…LoopOver has seen this pull request and is waiting on CI checks to finish before reviewing it. This comment will update once the review runs. 🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed · 🟨 Waiting |
|
Superagent didn't find any vulnerabilities or security issues in this PR. |
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
metagraphed-ui | a71cdcc | Commit Preview URL Branch Preview URL |
Jul 28 2026, 05:12 AM |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #8466 +/- ##
=======================================
Coverage 97.82% 97.82%
=======================================
Files 419 419
Lines 29179 29179
Branches 10958 10958
=======================================
Hits 28545 28545
Misses 143 143
Partials 491 491 🚀 New features to boost your workflow:
|
This was referenced Jul 28, 2026
JSONbored
added a commit
that referenced
this pull request
Jul 28, 2026
A clean main build measures 339.25 KB gzipped against the 340 KB budget -- Math.ceil rounds to 340, zero headroom -- the same trap the 320 -> 340 bump (#8266) already fixed once, one tier later. Two unrelated open PRs (#8465, #8466) both failed on this simultaneously with real measured deltas under 100 bytes each, confirming the gate was blocking on ordinary build-to-build gzip variance, not either PR's own regression. 360 restores ~6% headroom, matching the 320 -> 340 bump's own margin. Verified against a fresh local build: 340 KB / 360 KB budget. Closes #8468
JSONbored
force-pushed
the
fix/8365-stream-hook-hardening
branch
from
July 28, 2026 01:21
ee4be0e to
b8c5ecb
Compare
JSONbored
force-pushed
the
feat/8366-activity-aggregation
branch
from
July 28, 2026 01:23
9e1e941 to
91b487e
Compare
Subnet detail's Recent Activity/Activity tab showed five near-identical rows whenever a busy epoch fired the same event kind repeatedly -- the audit's own monotony finding. #8445/#8452 already wired the shared-hook subscription and a scoped LIVE affordance for this table; #8365 hardened it further (visibility gating, a shared ticker instead of per-row timers, a zero-layout-shift status chip). The one requirement a verification pass found still missing was the aggregation rule itself. aggregateActivityEvents (new, pure, unit-tested directly): groups CONSECUTIVE same-kind events -- adjacent in the given (newest-first) order -- into one row once they land within 15 minutes of the group's newest member. "Consecutive" is literal: a same-kind event that resumes after a different kind interrupts it starts a fresh group rather than retroactively merging into an earlier, unrelated occurrence of the same kind. An event missing observed_at never joins a group -- there's no timestamp to prove the "within 15 minutes" claim, matching this app's own "never assert something unverifiable" convention elsewhere (registry-ticker's "never a fabricated number", etc.). Runs over whatever `events` array ActivityTableLoader already has -- refreshed by a live stream event or the existing poll alike -- so exactly one rendering path covers both modes, per the issue's own requirement. ActivityGroupRow: a group of one renders through the extracted ActivityEventRow completely unchanged (byte-for-byte identical to every row before this PR). A group of more than one collapses to a summary row -- EventKindCell's own "× N · last Mm" (the issue's worked-example format), the newest member's block/time, and the shared hotkey when every member has the SAME one ("multiple" otherwise) -- clickable to reveal the individual member rows nested beneath it. Verified against live production data: a real repeated-kind run ("Stake added × 4 · last 1m") collapses and expands correctly. Also surfaced (and flagged on the issue, not silently worked around) that this subnet's weight-setting traffic alternates two different kinds strictly back-to- back, so literal same-kind-adjacent grouping doesn't collapse that specific interleaved pattern -- correct per the issue's own "consecutive" wording, not a bug, but worth knowing. Not attempted here (noted on the issue): the entrance-animation portion of requirement 4 -- a separate, smaller polish item left for a follow-up rather than bundled into an already-substantial aggregation change. Closes #8366
JSONbored
force-pushed
the
feat/8366-activity-aggregation
branch
from
July 28, 2026 05:08
91b487e to
a71cdcc
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #8366 — with a documented scope note posted first (#8366 (comment)): the shared-hook subscription and scoped LIVE affordance were already shipped (#8445/#8452, hardened by #8365); this PR is narrowly the one remaining requirement — the 15-minute aggregation rule itself.
What changed
aggregateActivityEvents(new, pure, unit-tested directly): groups CONSECUTIVE same-kind events — adjacent in the given newest-first order — into one row once they land within 15 minutes of the group's newest member. "Consecutive" is literal: a same-kind event that resumes after a different kind interrupts it starts a fresh group rather than retroactively merging into an earlier occurrence. An event missingobserved_atnever joins a group — no timestamp to prove the "within 15 minutes" claim.Runs over whatever
eventsarrayActivityTableLoaderalready has — refreshed by a live stream event or the existing poll alike — so there's exactly one rendering path for both modes, per the issue's own text.ActivityGroupRow: a group of one renders through the extractedActivityEventRowcompletely unchanged (byte-for-byte identical to every row before this PR). A group of more than one collapses to a summary row —EventKindCell's own "× N · last Mm" (the issue's worked-example format), the newest member's block/time, and the shared hotkey when every member has the same one ("multiple" otherwise) — clickable to reveal the individual member rows nested beneath it.Verified against live data
Confirmed against real production data via a running dev server: a genuine repeated-kind run ("Stake added × 4 · last 1m") collapses correctly, and clicking it expands to exactly 4 nested rows (row count 80 → 84,
aria-expandedtoggling false → true).This also surfaced something worth knowing, flagged on the issue rather than worked around: this subnet's actual weight-setting traffic alternates "Timelocked weights revealed" and "Weights set" strictly back-to-back, so literal same-kind-adjacent grouping doesn't collapse that specific interleaved pattern — each kind interrupts the other before either repeats. That's the spec's own "consecutive" wording working exactly as written, not a bug — but it means the single most repetitive real pattern on this subnet isn't the one this aggregation shrinks. A "commit+reveal pair" heuristic would be a materially different, more speculative policy than what was asked for, so I didn't silently expand scope to cover it.
Not attempted here (noted on the issue): the entrance-animation portion of requirement 4 — a separate, smaller polish item for a follow-up rather than bundled into an already-substantial change. Requirement 4's other pieces (visibility gating, no per-row timers, fallback DOM parity) are already covered by #8365 for this same table.
Screenshots
The desktop-light "after" shows a real collapsed row in the captured data ("Stake added × 2 · last 0m" with the collapse chevron) — the expand/collapse interaction itself (screenshots can't show a click) was verified directly against the DOM as described above.
Validation
No API, schema, or generated-contract surface touched.