LemmyNet/lemmy · error

activity is from before lemmy 0.19

Error message

activity is from before lemmy 0.19

What it means

This error is thrown in send_retry_loop when an outgoing federated activity has no actor_apub_id. Lemmy 0.19 changed activity storage so SentActivity always records the actor's ActivityPub ID; activities persisted by older 0.18-era code lack that field, and sending them is unsupported. The loop aborts rather than sending an activity whose origin cannot be resolved.

Source

Thrown at crates/apub/send/src/send.rs:114

impl SendRetryTask<'_> {
  // this function will return successfully when (a) send succeeded or (b) worker cancelled
  // and will return an error if an internal error occurred (send errors cause an infinite loop)
  pub async fn send_retry_loop(self) -> Result<()> {
    let SendRetryTask {
      activity,
      object,
      inbox_urls,
      report,
      initial_fail_count,
      domain,
      context,
      stop,
    } = self;
    debug_assert!(!inbox_urls.is_empty());

    let pool = &mut context.pool();
    let Some(actor_apub_id) = &activity.actor_apub_id else {
      return Err(anyhow::anyhow!("activity is from before lemmy 0.19"));
    };
    let actor = get_actor_cached(pool, activity.actor_type, actor_apub_id)
      .await
      .context("failed getting actor instance (was it marked deleted / removed?)")?;

    let object: DummyActivity = serde_json::from_value(object.clone())?;
    let object = WithContext::new(object, FEDERATION_CONTEXT.deref().clone());
    let requests = SendActivityTask::prepare(&object, actor.as_ref(), inbox_urls, &context).await?;
    for task in requests {
      // usually only one due to shared inbox
      tracing::debug!("sending out {}", task);
      let mut fail_count = initial_fail_count;
      while let Err(e) = task.sign_and_send(&context).await {
        fail_count += 1;
        report.send(SendActivityResult::Failure {
          fail_count,
          // activity_id: activity.id,
        })?;

View on GitHub (pinned to 439734dd63)

Solutions

  1. Clear out pre-0.19 pending federation activities (let the queue skip/fail them or purge stale rows from the activity send state)
  2. Ensure the 0.19 migration ran fully before starting the federation send loop
  3. Regenerate or re-send affected activities with 0.19+ code so actor_apub_id is populated
  4. If you maintain custom federation code, always set actor_apub_id when creating SentActivity

Example fix

// before
let activity = SentActivity { object, .. }; // actor_apub_id left None (pre-0.19 row)
// after
let activity = SentActivity { actor_apub_id: Some(actor_apub_id), object, .. }; // require actor after 0.19
Defensive patterns

Strategy: validation

Validate before calling

if activity.actor_apub_id.is_none() {
  // skip pre-0.19 activity
  return Ok(());
}

Type guard

fn has_actor(a: &SentActivity) -> bool { a.actor_apub_id.is_some() }

Prevention

When it happens

Trigger: Calling the federation send path with a SentActivity whose actor_apub_id is None — typically an activity row created before upgrading to Lemmy 0.19 that is being retried/sent after the upgrade.

Common situations: Operators upgrade a Lemmy instance from 0.18 to 0.19 and the federation queue picks up leftover pre-0.19 activities in the send queue; DB migration leftovers or partial upgrade paths surface old rows with no actor AP ID.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors


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