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
- Clear out pre-0.19 pending federation activities (let the queue skip/fail them or purge stale rows from the activity send state)
- Ensure the 0.19 migration ran fully before starting the federation send loop
- Regenerate or re-send affected activities with 0.19+ code so actor_apub_id is populated
- 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
- Complete 0.19 migrations before starting the federation send loop
- Purge pre-0.19 pending activities after upgrading
- Always populate actor_apub_id when creating activities in custom code
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
- err getting actor {actor_type:?} {actor_apub_id}: {e:?}
- {}: next id to send is not as expected: {:?} != {:?}
- err getting activity: {e:?}
- err getting id: {e:?}
- err getting local site: {e:?}
AI-assisted analysis of LemmyNet/lemmy@439734dd63 (2026-09-06).
Data as JSON: /api/errors/f5fd1ed7567dbcbe.
Report an issue: GitHub.