You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(cli): use wall-clock timestamp for repository announcement updates - #2901
When executing buzz repos protect set or buzz repos protect remove on a repository announcement created more than 15 minutes ago, the relay rejects the event with:
relay error 400: invalid: event timestamp too far from server time
Root Cause
build_updated_repo_announcement in crates/buzz-cli/src/commands/repos.rs derived the replacement announcement event's timestamp strictly as existing.created_at + 1.
If the existing repo announcement was published more than 15 minutes ago, the derived timestamp existing.created_at + 1 was also more than 15 minutes in the past relative to server wall-clock time (now).
The relay enforces MAX_TIMESTAMP_DRIFT_SECS = 900 (±15 minutes) on all ingested events, causing any update to an announcement older than 15 minutes to be rejected as stale.
Implementation
Updated build_updated_repo_announcement to calculate the replacement event's timestamp as now.max(existing.created_at + 1):
Strictly advances existing.created_at to satisfy NIP-33 parameterized replaceable event requirements.
Uses current wall-clock time now when updating older announcements, eliminating timestamp drift rejection at the relay.
Regression Coverage
Added unit test protection_update_uses_wall_clock_time_for_stale_repo_announcements in crates/buzz-cli/src/commands/repos.rs verifying that repo announcements published in the past receive replacement timestamps matching current wall-clock time while advancing past the original timestamp.
🦾 DCO sign-off is failing on this PR. Each commit needs a Signed-off-by trailer matching your GitHub-verified email. See the contributing guide for details. Quick fix: git commit --amend --signoff (single commit) or git rebase --signoff HEAD~N (multiple commits), then force-push.
The current range is 7852b1670c7588875fc43ef2613c8348893d5ab6...f699ba125726af4fbb4360783a224ad822da7477.
A new review must complete for this exact range. When manual authorization
is required, a user with write access must comment exactly @buzz-security-review f699ba125726af4fbb4360783a224ad822da7477 to authorize a new review.
Any previous review applies only to its recorded range.
Added the DCO Signed-off-by trailer and force-pushed. The Security check failure comes from RUSTSEC-2026-0216 and RUSTSEC-2026-0219 in the dependency tree, not from this PR, which only changes crates/buzz-cli/src/commands/repos.rs.
This branch has not been deployed
No deployments
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
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.
Linked Issue
Fixes #2876
Observed Failure
When executing
buzz repos protect setorbuzz repos protect removeon a repository announcement created more than 15 minutes ago, the relay rejects the event with:Root Cause
build_updated_repo_announcementincrates/buzz-cli/src/commands/repos.rsderived the replacement announcement event's timestamp strictly asexisting.created_at + 1.If the existing repo announcement was published more than 15 minutes ago, the derived timestamp
existing.created_at + 1was also more than 15 minutes in the past relative to server wall-clock time (now).The relay enforces
MAX_TIMESTAMP_DRIFT_SECS = 900(±15 minutes) on all ingested events, causing any update to an announcement older than 15 minutes to be rejected as stale.Implementation
Updated
build_updated_repo_announcementto calculate the replacement event's timestamp asnow.max(existing.created_at + 1):existing.created_atto satisfy NIP-33 parameterized replaceable event requirements.nowwhen updating older announcements, eliminating timestamp drift rejection at the relay.Regression Coverage
Added unit test
protection_update_uses_wall_clock_time_for_stale_repo_announcementsincrates/buzz-cli/src/commands/repos.rsverifying that repo announcements published in the past receive replacement timestamps matching current wall-clock time while advancing past the original timestamp.Exact Validation Commands & Results
. ./bin/activate-hermit && cargo test -p buzz-cli-> 251 tests passed. ./bin/activate-hermit && cargo fmt --all-> Clean formatting. ./bin/activate-hermit && just check-> Passed (clippy, formatting, desktop, web, and mobile checks clean)git diff --check-> Passed with no whitespace issuesLimitations or Untested Platforms
None.
Unrelated Changes
No unrelated changes were included.