What causes "insert kind:30618: {e}" in block/buzz?

Read wrapped {e}: if it's a DB connection error, check Postgres health and retry the announcement.

insert kind:30618: {e}

Error message

insert kind:30618: {e}

What it means

After building the initial kind:30618 ref-state event, emit_initial_ref_state persists it with insert_event_with_serving_write_guard under the community serving lease. This error wraps DB insert failure — the initial ref snapshot could not be stored, so repo announcement fails (distinct from the non-fatal message when was_inserted is false).

Source

Thrown at crates/buzz-relay/src/handlers/side_effects.rs:2942

    repo_id: &str,
) -> anyhow::Result<()> {
    use crate::api::git::manifest_event::{build_ref_state_event, RefStateInputs};
    use std::collections::BTreeMap;

    let empty_refs: BTreeMap<String, String> = BTreeMap::new();
    let inputs = RefStateInputs {
        repo_id,
        head: DEFAULT_HEAD,
        refs: &empty_refs,
        actor_pubkey_hex: owner_hex,
    };
    let event = build_ref_state_event(&inputs, &state.relay_keypair)
        .map_err(|e| anyhow::anyhow!("build_ref_state_event: {e}"))?;
    let (stored, was_inserted) = state
        .db
        .insert_event_with_serving_write_guard(lease, &event, None)
        .await
        .map_err(|e| anyhow::anyhow!("insert kind:30618: {e}"))?;
    if was_inserted {
        // Routed through the guarded send path for uniformity; the access gate
        // no-ops for this globally-scoped (channel_id = None) ref-state event.
        crate::handlers::event::fan_out_event_to_local_subscribers(
            state,
            tenant.community(),
            &stored,
        )
        .await;
    }
    Ok(())
}

/// Reconcile every community's event-backed NIP-43 membership view.
///
/// `relay_members` is canonical. A snapshot is rebuilt only when it is absent
/// or its member/role set differs from the canonical rows. This makes the sweep
/// safe to run at startup and periodically without producing an event stream

View on GitHub (pinned to dad5a33865)

Solutions

Read wrapped {e}: if it's a DB connection error, check Postgres health and retry the announcement.
If the lease was invalidated, treat like the other fence errors — retry after the deletion settles.
Check whether a kind:30618 for this repo/lease already exists (was_inserted=false path) — the state may already be correct.
Verify migrations are current (`just setup` runs migrations) if the error mentions missing columns/tables.

Defensive patterns

Strategy: retry

Validate before calling

sqlx::query("SELECT 1").fetch_one(&state.db).await?; // DB reachable
anyhow::ensure!(lease_valid, "serving lease must be held before insert");

Try / catch

match state.db.insert_event_with_serving_write_guard(lease, &event, None).await {
    Err(e) if is_transient_db(&e) => {
        backoff_retry(|| reannounce(repo_id), 3).await
    }
    Err(e) => Err(anyhow!("insert kind:30618: {e:#}")),
    Ok((stored, _)) => Ok(stored),
}

Prevention

Keep Postgres connection pools sized for announcement bursts.
Ensure migrations are applied before relay startup.
Treat duplicate-insert errors by checking existing kind:30618 state first.

When it happens

Trigger: DB unreachable or erroring during handle_git_repo_announcement_inner; the serving lease was invalidated (community deletion closed the fence) so the guarded insert refuses; schema/constraint violation on the events table.

Common situations: Postgres outage or connection-pool exhaustion during an announcement burst; deletion racing with the insert; duplicate insert races that surface as constraint errors instead of was_inserted=false.

Related errors

AI-assisted analysis of block/buzz@dad5a33865 (2026-08-30). Data as JSON: /api/errors/d0ffa0e1030a2b34. Report an issue: GitHub.