fix(backend): skip inbox activities without an actor instead of throwing TypeError

[sasagar]

What

Inbox activities delivered without an actor property crash the inbox queue job with an opaque error instead of being skipped:

TypeError: Cannot read properties of undefined (reading 'id')
    at getApId (packages/backend/src/core/activitypub/type.ts)
    at InboxProcessorService.process (packages/backend/src/queue/processors/InboxProcessorService.ts)

This PR:

1. Guards getApId() against null / undefined, so it throws the intended Error('cannot determine id') instead of a raw TypeError (also fixes the detemine → determine typo).
2. Rejects actor-less activities early in InboxProcessorService.process() with Bull.UnrecoverableError, so they are skipped cleanly like other invalid inputs (and are not retried 128×).

Fixes #17557. Related: #12720.

Why

InboxProcessorService.process() calls getApId(activity.actor) in several places before any validation (the isDelete short-circuit getApId(activity.actor) === getApId(activity.object), and getAuthUserFromApId(getApId(activity.actor))). When activity.actor is missing, getApId(undefined) evaluates undefined.id and throws.

On a small federated instance this produces on the order of ~100 failed jobs/day from malformed / actor-less deliveries, flooding error tracking and masking real problems.

Additional info

• No behaviour change for valid activities: every activity that reaches this code already requires an actor (it is used immediately for HTTP-Signature / authorship checks), so an activity without one was always going to fail — this just fails it cleanly and early instead of with a confusing TypeError.
• I was not able to spin up a full local federation instance to reproduce end-to-end; the diagnosis is from production stack traces, and the logic was verified by inspection. InboxProcessorService has no unit test suite (cf. fix: change bare activity.actor to getApId(activity.actor) in InboxPr… #17340).

Checklist

• Read the contribution guide
• Test working in a local environment
• (If needed) Add story of storybook
• (If needed) Update CHANGELOG.md
• (If possible) Add tests

[codecov]

Codecov Report

❌ Patch coverage is 25.00000% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 24.92%. Comparing base (7bd8f81) to head (03e0b94).

Files with missing lines	Patch %	Lines
...ges/backend/src/server/ActivityPubServerService.ts	0.00%	4 Missing and 1 partial ⚠️
packages/backend/src/core/activitypub/type.ts	66.66%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop   #17558      +/-   ##
===========================================
- Coverage    24.95%   24.92%   -0.03%     
===========================================
  Files         1161     1161              
  Lines        39633    39637       +4     
  Branches     11047    11048       +1     
===========================================
- Hits          9889     9880       -9     
- Misses       23831    23841      +10     
- Partials      5913     5916       +3     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

このPRによるapi.jsonの差分
差分はありません。
Get diff files from Workflow Page

[github-actions]

Backend memory usage comparison

Before GC

Metric	base (MB)	head (MB)	Diff (MB)	Diff (%)
VmRSS	305.38 MB	308.76 MB	+3.38 MB	+1.10%
VmHWM	305.38 MB	308.76 MB	+3.38 MB	+1.10%
VmSize	23169.82 MB	23173.01 MB	+3.19 MB	+0.01%
VmData	1370.49 MB	1373.83 MB	+3.33 MB	+0.24%

After GC

Metric	base (MB)	head (MB)	Diff (MB)	Diff (%)
VmRSS	305.46 MB	308.84 MB	+3.37 MB	+1.10%
VmHWM	305.46 MB	308.84 MB	+3.37 MB	+1.10%
VmSize	23170.15 MB	23173.26 MB	+3.10 MB	+0.01%
VmData	1370.83 MB	1374.08 MB	+3.25 MB	+0.23%

After Request

Metric	base (MB)	head (MB)	Diff (MB)	Diff (%)
VmRSS	305.90 MB	309.17 MB	+3.26 MB	+1.06%
VmHWM	305.90 MB	309.17 MB	+3.26 MB	+1.06%
VmSize	23170.24 MB	23173.26 MB	+3.02 MB	+0.01%
VmData	1370.91 MB	1374.08 MB	+3.16 MB	+0.23%

See workflow logs for details

[syuilo]

IActivity.actor 自体はnonNullに定義されていますが、これは型定義を修正すべきでしょうか？

[syuilo]

もしくは不正な形式のジョブデータをそもそもジョブキューに積むべきではないかもしれません

[sasagar]

@syuilo

ありがとうございます。2点ともおっしゃる通りで、根本は inbox エンドポイントの request.body as IActivity（ActivityPubServerService）という未検証キャストだと思います。信頼できない入力を検証せず IActivity と見なしてキュー投入しているため、actor 欠落のような構造的に不正なボディがそのまま流れていました。

その観点では、enqueue 時点で検証し不正なジョブはキューに積まないのが一番良さそうです:

• inbox ハンドラで queueService.inbox() の前にボディの最低限の構造（actor の存在など）を検証し、満たさなければ 400 等で返してキュー投入しない
• これにより無駄なリトライも発生せず、HTTP 層で送信元へ適切に応答できます
• 型の乖離（前コメント）も、この境界で緩い型から検証して narrow する形にすれば解消できます

ただ inbox は意図的に軽量で、重い検証（署名・actor 解決）は processor 側に寄せていると理解しています。なので enqueue 時の検証は構造的・低コストなチェックに留めるのが良いかと思います

getApId の null ガードは、getOneApId が空配列で getApId(undefined) を踏むケースもあるため、独立した汎用防御として残す想定です。

この方針で PR を更新してよければ対応しようかと思います。processor 側の早期ガードは defense-in-depth として残すか、enqueue 検証に一本化するかは判断をお願いできたらと...。

[syuilo]

それで良さそうです。
processor側は型がnon nullになっている以上nullチェックは要らないと思います。

[sasagar]

@syuilo
かしこまりです。そうしたはそっちで再対応するので少しお待ちを……

[sasagar]

@syuilo

ご指摘の方針で対応しました。

• enqueue 時に検証: ActivityPubServerService の inbox ハンドラで、未検証の request.body（緩い型）から構造を検証し、非オブジェクトや actor 欠落のアクティビティは 400 を返してキューに積まないようにしました。認証できないボディを processor まで流さず、無駄なリトライも発生しません。
• processor 側の null チェックは削除: ご指摘どおり IActivity.actor は non-null なので、enqueue 検証後は不要になりました。
• getApId() の防御は残しつつ型を正直に: getOneApId が空配列の value[0]（= undefined）を渡しうるため、引数型を string | IObject | undefined に広げてガードを型レベルでも妥当にしました（あわせて元の detemine → determine の typo 修正も維持）。

ご確認よろしくお願いします。

[syuilo]

🙏🏻