How Should a Federated Server Handle a Repeated Activity?

Retries make repetition normal

Federated servers communicate over networks that can fail or time out. A sender may retry after it cannot tell whether a receiver completed an earlier request. The same activity can therefore arrive more than once, even when the sender intended one action. Treating every arrival as new can create duplicate notifications, repeated reactions, or other unintended effects. A receiver should design processing with repeated delivery in mind.

Use identity, not just matching content

When an activity has a stable identifier, the receiver can use it as a key for deduplication. Before applying a new effect, check whether that activity identity has already been processed or recorded. Two activities with similar text are not necessarily the same activity, while a repeated delivery of the same identified activity should not normally be treated as a second independent action.

For example, if a server receives activity ID X, stores it, and applies its effect, then later receives ID X again, it can recognize the repeat and avoid applying the effect twice. It may still need to complete a response or other protocol handling for the repeated request, but that is separate from creating a second copy of the action.

Make the processing steps safe

Deduplication works best when recording the activity and applying its effect are coordinated. If the system applies an effect and crashes before saving the identifier, a retry may apply it again. If it records the identifier before the effect and crashes, the effect may never happen. A durable processing state or transaction strategy can reduce this gap. For work delegated to asynchronous jobs, include the activity identity in the job so that later retries can check the same key.

Keep validation separate from deduplication. An identifier seen before does not mean every request carrying it should bypass authentication or integrity checks. The receiver should still apply the appropriate acceptance rules, while making duplicate handling consistent.

Retain enough information to explain outcomes

Store the identifiers and processing status for a period suited to the system’s retry and retention behavior. If records are discarded too soon, a delayed repeat can look new; retaining everything forever may be impractical. The right policy depends on operational needs and privacy requirements. A clear log can distinguish “first accepted,” “recognized duplicate,” and “rejected,” helping operators diagnose delivery without inventing a new user-visible action for every network retry.