The "Last event" figure in the Statistics block on the webhook page now shows how long ago the newest event arrived, as its two largest units: 59s, 1m1s, 23h59m, 3d4h. Its tooltip is the full time in UTC, in the format the block showed before. With no event it still shows none, with no tooltip. This builds the definition of done in #567 (comment).
The figure is worked out when the page is served, from the same now as the block's other figures. relativeTime in internal/handlers/webhook_stats.go does the formatting. WebhookStats gains LastEvent and LastEventUTC next to LastEventAt, the same pairing the entrypoint rows already use.
Things the diff does not make obvious:
The browser check records a last event 3 days, 4 hours and 30 minutes ago on the shared test webhook. Checks that run after it see that last event.
Page tests that looked for the old timestamp in the block now look for it in the tooltip.
Disclosures:
Judgement call: the unit test has one case beyond the listed boundaries, 400d3h, to pin days as the largest unit.
Judgement call: the page test for an event that has just arrived accepts any whole number of seconds (\d+s), because the exact figure depends on how long the test takes.
Not changed: the webhook list page still shows the full timestamp, since the definition of done says nothing else changes.
No document describes this figure, so no document changed.
Model: opus-5-5
The "Last event" figure in the Statistics block on the webhook page now shows how long ago the newest event arrived, as its two largest units: `59s`, `1m1s`, `23h59m`, `3d4h`. Its tooltip is the full time in UTC, in the format the block showed before. With no event it still shows `none`, with no tooltip. This builds the definition of done in https://git.eeqj.de/sneak/webhooker/issues/567#issuecomment-155878.
The figure is worked out when the page is served, from the same `now` as the block's other figures. `relativeTime` in `internal/handlers/webhook_stats.go` does the formatting. `WebhookStats` gains `LastEvent` and `LastEventUTC` next to `LastEventAt`, the same pairing the entrypoint rows already use.
Things the diff does not make obvious:
- The browser check records a last event 3 days, 4 hours and 30 minutes ago on the shared test webhook. Checks that run after it see that last event.
- Page tests that looked for the old timestamp in the block now look for it in the tooltip.
Disclosures:
- Judgement call: the unit test has one case beyond the listed boundaries, `400d3h`, to pin days as the largest unit.
- Judgement call: the page test for an event that has just arrived accepts any whole number of seconds (`\d+s`), because the exact figure depends on how long the test takes.
- Not changed: the webhook list page still shows the full timestamp, since the definition of done says nothing else changes.
- No document describes this figure, so no document changed.
Model: opus-5-5
The Statistics block's "Last event" figure now shows how long ago the
newest event arrived, as its two largest units ("59s", "1m1s", "3d4h"),
worked out when the page is served. Its tooltip is the full time in
UTC. With no event it still shows "none", without a tooltip.
Model: opus-5-5
internal/handlers/webhook_stats_test.go, TestRelativeTime: the future-time case is exactly one hour ahead, which relativeTime writes as 0s even without its clamp to zero (max(now.Sub(at), 0)). So the case would not catch the clamp's removal, and the rule from #567 (comment) that a future time shows 0s is not pinned. Acceptable: a future time that is not a whole number of minutes ahead, such as 90 seconds, which without the clamp would come out as -30s.
Model: opus-5-5
Review failed: needs rework.
- `internal/handlers/webhook_stats_test.go`, `TestRelativeTime`: the future-time case is exactly one hour ahead, which `relativeTime` writes as `0s` even without its clamp to zero (`max(now.Sub(at), 0)`). So the case would not catch the clamp's removal, and the rule from https://git.eeqj.de/sneak/webhooker/issues/567#issuecomment-155878 that a future time shows `0s` is not pinned. Acceptable: a future time that is not a whole number of minutes ahead, such as 90 seconds, which without the clamp would come out as `-30s`.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The "Last event" figure in the Statistics block on the webhook page now shows how long ago the newest event arrived, as its two largest units:
59s,1m1s,23h59m,3d4h. Its tooltip is the full time in UTC, in the format the block showed before. With no event it still showsnone, with no tooltip. This builds the definition of done in #567 (comment).The figure is worked out when the page is served, from the same
nowas the block's other figures.relativeTimeininternal/handlers/webhook_stats.godoes the formatting.WebhookStatsgainsLastEventandLastEventUTCnext toLastEventAt, the same pairing the entrypoint rows already use.Things the diff does not make obvious:
Disclosures:
400d3h, to pin days as the largest unit.\d+s), because the exact figure depends on how long the test takes.Model: opus-5-5
The Statistics block's "Last event" figure now shows how long ago the newest event arrived, as its two largest units ("59s", "1m1s", "3d4h"), worked out when the page is served. Its tooltip is the full time in UTC. With no event it still shows "none", without a tooltip. Model: opus-5-5Review failed: needs rework.
internal/handlers/webhook_stats_test.go,TestRelativeTime: the future-time case is exactly one hour ahead, whichrelativeTimewrites as0seven without its clamp to zero (max(now.Sub(at), 0)). So the case would not catch the clamp's removal, and the rule from #567 (comment) that a future time shows0sis not pinned. Acceptable: a future time that is not a whole number of minutes ahead, such as 90 seconds, which without the clamp would come out as-30s.Model: opus-5-5
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.