block/buzz · error

insert community

Error message

insert community

What it means

This is `.expect("insert community")` on a raw `sqlx::query("INSERT INTO communities (id, host) VALUES ($1, $2)")` executed against both writer and replica scratch pools. It panics if the INSERT fails — most often because the `communities` table does not exist in the freshly created scratch database (migrations were never applied), or because a duplicate community id/host violates a constraint on the second pool.

Source

Thrown at crates/buzz-db/src/runtime/tests.rs:1679

/// fresh proved entry ⇒ replica (bounded arm); over-budget entry ⇒
/// writer. Divergent membership rows prove which pool answered.
#[tokio::test]
#[ignore = "requires Postgres"]
async fn is_relay_member_is_bounded_routed_and_fails_closed() {
    let admin = PgPool::connect(&admin_url().await)
        .await
        .expect("connect admin");
    let (writer, wname) = create_scratch_db(&admin, "mem_w").await;
    let (replica, rname) = create_scratch_db(&admin, "mem_r").await;

    let community = Uuid::new_v4();
    for pool in [&writer, &replica] {
        sqlx::query("INSERT INTO communities (id, host) VALUES ($1, $2)")
            .bind(community)
            .bind(format!("member-routing-{}.example", community.simple()))
            .execute(pool)
            .await
            .expect("insert community");
    }
    let cid = CommunityId::from_uuid(community);
    let writer_only = "aa".repeat(32);
    let replica_only = "bb".repeat(32);
    relay_members::add_relay_member(&writer, cid, &writer_only, "member", None)
        .await
        .expect("seed writer member");
    relay_members::add_relay_member(&replica, cid, &replica_only, "member", None)
        .await
        .expect("seed replica member");

    let mut db = Db::from_pools(writer.clone(), replica.clone());
    db.fence().force_open_for_tests(chrono::Utc::now());

    // Budget unset ⇒ bounded arm disabled ⇒ writer.
    assert!(
        db.is_relay_member(cid, &writer_only)
            .await

View on GitHub (pinned to dad5a33865)

Solutions

  1. Apply buzz-db migrations to each scratch DB immediately after `create_scratch_db` before seeding.
  2. Drop leftover `mem_w`/`mem_r` scratch databases from previous failed runs.
  3. Print the sqlx error (`.unwrap_or_else(|e| panic!("insert community: {e}"))`) to see constraint vs missing-table.
  4. Confirm the `communities` schema still matches this test's INSERT columns after schema changes.
  5. Check both pool inserts succeed — the loop runs on writer and replica; the label doesn't say which failed.

Example fix

// before
sqlx::query("INSERT INTO communities (id, host) VALUES ($1, $2)")
    .bind(community).bind(host).execute(pool).await.expect("insert community");
// after
sqlx::query("INSERT INTO communities (id, host) VALUES ($1, $2)")
    .bind(community).bind(host).execute(pool).await
    .unwrap_or_else(|e| panic!("insert community on {} failed: {e}", pool_name));
Defensive patterns

Strategy: validation

Validate before calling

// Confirm the table exists before seeding
let ok: bool = sqlx::query_scalar(
    "SELECT EXISTS (SELECT 1 FROM information_schema.tables WHERE table_name='communities')")
    .fetch_one(pool).await.unwrap_or(false);
assert!(ok, "scratch DB not migrated — communities table missing");

Type guard

async fn table_exists(pool: &sqlx::PgPool, name: &str) -> bool {
    sqlx::query_scalar("SELECT EXISTS (SELECT 1 FROM information_schema.tables WHERE table_name=$1)")
        .bind(name).fetch_one(pool).await.unwrap_or(false)
}

Try / catch

match insert.execute(pool).await {
    Ok(_) => {}
    Err(e) => panic!("insert community failed (migrated? unique host?): {e}"),
}

Prevention

When it happens

Trigger: Running `is_relay_member_is_bounded_routed_and_fails_closed` where `create_scratch_db` produced empty (unmigrated) databases; the host string collides with an existing row via a unique constraint; the connection to one pool dropped.

Common situations: Test harness that creates scratch DBs from `template0`/`template1` without running buzz-db migrations; leftover scratch DB with the same host from a crashed prior run; SQL syntax/type drift after a schema change.

Related errors


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