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
- Check the inner debug error for the underlying diesel/DB cause
- Verify database connectivity and connection pool configuration
- Ensure schema migrations completed so sent_activities is queryable
- 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
- Retry transient DB failures with backoff
- Ensure migrations finish before workers query sent_activities
- Size the connection pool for all concurrent federation workers
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
- err getting actor {actor_type:?} {actor_apub_id}: {e:?}
- err getting activity: {e:?}
- activity is from before lemmy 0.19
- {}: next id to send is not as expected: {:?} != {:?}
- err getting local site: {e:?}
AI-assisted analysis of LemmyNet/lemmy@439734dd63 (2026-09-06).
Data as JSON: /api/errors/48f8b806d32f43ce.
Report an issue: GitHub.