LemmyNet/lemmy · error

err getting id: {e:?}

Error message

err getting id: {e:?}

What it means

get_latest_activity_id wraps failures of the `SELECT max(id)` query on sent_activities into this anyhow error. Callers use the latest id to compute the next id to send, so this represents a failure of the cheap lookup query, not of sending itself.

Source

Thrown at crates/apub/send/src/util.rs:214

/// return the most current activity id (with 1 second cache)
pub(crate) async fn get_latest_activity_id(pool: &mut DbPool<'_>) -> Result<Option<ActivityId>> {
  static CACHE: LazyLock<Cache<(), Option<ActivityId>>> = LazyLock::new(|| {
    Cache::builder()
      .time_to_live(*CACHE_DURATION_LATEST_ID)
      .build()
  });
  CACHE
    .try_get_with((), async {
      use lemmy_db_schema_file::schema::sent_activity::dsl::{id, sent_activity};
      let conn = &mut get_conn(pool).await?;
      let latest_id: Option<ActivityId> = sent_activity
        .select(diesel::dsl::max(id))
        .get_result(conn)
        .await?;
      anyhow::Result::<_, anyhow::Error>::Ok(latest_id)
    })
    .await
    .map_err(|e| anyhow::anyhow!("err getting id: {e:?}"))
}

/// the domain name is needed for logging, pass it to the stats printer so it doesn't need to look
/// up the domain itself
#[derive(Debug)]
pub(crate) struct FederationQueueStateWithDomain {
  pub domain: String,
  pub state: FederationQueueState,
}

View on GitHub (pinned to 439734dd63)

Solutions

  1. Check the inner debug error for the underlying diesel/DB cause
  2. Verify database connectivity and connection pool configuration
  3. Ensure schema migrations completed so sent_activities is queryable
  4. Restart/retry the federation worker once the DB is healthy
Defensive patterns

Strategy: retry

Try / catch

loop {
  match get_latest_activity_id(pool).await {
    Ok(id) => break id,
    Err(e) if is_transient(&e) => { sleep(backoff()).await; }
    Err(e) => return Err(e),
  }
}

Prevention

When it happens

Trigger: Any DB error while running the max(id) query against sent_activities — connection loss, pool exhaustion, permission problems, or the table being unavailable/locked (e.g. during migration).

Common situations: Database restart or failover while the federation worker is running; migrations locking sent_activities; connection pool exhaustion under heavy federation load.

Understand the failure class

Background: "query failed", "%w: SQL error" — wrapped database query errors in Go libraries explained — this error's family across 3 libraries.

Related errors


AI-assisted analysis of LemmyNet/lemmy@439734dd63 (2026-09-06). Data as JSON: /api/errors/48f8b806d32f43ce. Report an issue: GitHub.