Repository navigation
Conversation
…k#2876) build_updated_repo_announcement stamped replacements at existing.created_at+1, which the relay's ±900s MAX_TIMESTAMP_DRIFT_SECS check rejects once the head is >15min stale — making protect set/remove and bind permanently fail. max(now, head+1) keeps the leapfrog floor while restoring wall-clock freshness on a live writer. Single shared choke point fixes all three commands. Signed-off-by: Sarthak Singh <[email protected]>
Contributor
Contributor
Author
|
@chessing234 thanks — that's exactly the reasoning: |
This branch has not been deployed
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.
Problem
buzz repos protect set/protect remove/bindpermanently fail 15 minutes after a repo is announced (#2876).build_updated_repo_announcementstamped the replacement announcement atexisting.created_at + 1, but the relay rejects any event whosecreated_atdrifts more thanMAX_TIMESTAMP_DRIFT_SECS(±900s) from server time. Since the advance is+1and never catches up, once an announcement is >15 min stale every mutation is rejected deterministically — branch protection becomes permanently unchangeable, andrepos bind(the documented recovery for #2877) is unreachable. Independent repro by @A-PachecoT confirmed all three commands hit the same path.Fix
Stamp the replacement with
max(now, existing + 1):+1floor is preserved. A delayed writer still can't leapfrog an intervening update and silently erase metadata — if it observed a stale head, the floor keeps its replacement ahead of that head. Replay-protection intent unchanged.protect set,protect remove, andbindare all fixed by the same change.crates/buzz-cli/src/commands/repos.rs— the only file touched.Tests
assert_eq!(created_at, 101)) encoded the old semantics; relaxed to>= 101(the floor invariant they actually pin down — wall-clock now (2026+) always exceeds the100base, so behavior on a live writer is unchanged).updated_announcement_stays_within_relay_drift_window_for_stale_head: announcement made 2h ago → replacement drifts ≤900s from wall clock and advances past the stale head. This is the buzz repos protect set and repos protect remove are rejected by the relay's timestamp drift check on any repo announced more than 15 minutes ago #2876 regression, pinned.protection_set_preserves_metadata_and_protections: auth tag stripped, the matchingrefs/heads/mainrule replaced, unrelated protections + future metadata preserved, and the leapfrog guard verified.cargo test -p buzz-cli --lib repos::→ 17/17 green; fullbuzz-cli --libbaseline clean;cargo clippy -p buzz-cli --libclean.Behavior is timestamp-only — no relay change, no API change. Host: macOS
aarch64-apple-darwin; the path is platform-independent Rust.