block/buzz · error
repo announcement lost community serving lease on release: {
Error message
repo announcement lost community serving lease on release: {e} What it means
At the end of handle_git_repo_announcement_inner, serving_write.finish() releases the community serving lease. This error wraps a failure during release — the lease could not be cleanly finished, indicating the deletion fence state changed (e.g. community deletion began) or the lease release operation itself failed against the database.
Source
Thrown at crates/buzz-relay/src/handlers/side_effects.rs:2779
// re-announce should replay.
if reserved_by_this_attempt {
if let Err(e) =
emit_initial_ref_state(tenant, state, serving_write.lease(), &owner_hex, &repo_id).await
{
// Non-fatal: the manifest is the source of truth; this is just the
// derived notification. A failure here means subscribers miss the
// "repo now exists" event, but clone/push still works.
warn!(
repo_id = %repo_id,
owner = %owner_hex,
error = %e,
"failed to emit initial kind:30618 ref state (non-fatal)"
);
}
}
serving_write.finish().await.map_err(|e| {
anyhow::anyhow!("repo announcement lost community serving lease on release: {e}")
})?;
Ok(())
}
/// Default symbolic HEAD for a freshly-announced (empty) repo. Matches
/// `init.defaultBranch=main` (git ≥ 2.28) and the seed used by
/// `live_hydrate_empty_repo`. Pinned in one place so the seeded manifest
/// and the initial kind:30618 emission can't drift.
///
/// The first push's `cas_publish` overwrites this with the real symbolic
/// HEAD observed in the receive-pack workspace via standard CAS, so the
/// default is a stand-in, not a permanent commitment.
const DEFAULT_HEAD: &str = "refs/heads/main";
/// Seed the manifest-pointer for a newly-announced repo with an empty manifest.
///
/// Idempotent: a `CasOutcome::LostRace` is treated as success **only if** the
/// existing pointer names the same empty manifest digest. Any other pre-existingView on GitHub (pinned to dad5a33865)
Solutions
- Check whether the community is being deleted; the error is often a symptom of that race rather than a bug — re-run after deletion settles.
- Inspect wrapped {e} for DB-level causes (connection errors, lock timeouts) and address connectivity.
- Verify the announcement's writes committed; if the event was stored but the lease release failed, reconcile fence state before retrying.
- Retry the announcement; the fence will reject cleanly if the community is gone.
Defensive patterns
Strategy: try-catch
Try / catch
if let Err(e) = serving_write.finish().await {
tracing::error!("lease release failed: {e:#} — verify fence state manually");
// do not retry the announcement blindly; check whether writes committed first
} Prevention
- Confirm announcement writes committed before interpreting release failure as data loss.
- Monitor Postgres health; transient failures here are usually connectivity.
- Reconcile deletion fence state after any release failure before retrying.
When it happens
Trigger: The community deletion fence closes while the announcement handler is still finishing (emitting kind:30618 refs, etc.); DB failure during the finish() release call for the lease.
Common situations: Deletion racing with announcement completion; transient Postgres connectivity loss during lease release; long ref-state emission work extending lease lifetime into a deletion window.
Related errors
- repo announcement rejected by community deletion fence: {e}
- repo announcement lost community serving lease: {error}
- an admin cannot ban or time out a community owner or fellow
- classify mutation result: {e}
- BUZZ_RELAY_PRIVATE_KEY must be set when BUZZ_REQUIRE_AUTH_TO
AI-assisted analysis of block/buzz@dad5a33865 (2026-08-30).
Data as JSON: /api/errors/650fb59caad7271c.
Report an issue: GitHub.