Handle out-of-order events on a desk light

Status Light is a desk indicator driven by an integration you configure around your work tools. Events can reach that integration in a different order from the activity they describe. A delayed running update should not replace a newer completed result merely because it arrived last. Keep event identity and task progression separate from network arrival time.

Which task does the event belong to?

Extract the source's stable task identifier and any attempt or revision identifier relevant to the workflow. A retry may be a new attempt with its own progression, even when the displayed task name is unchanged. Use the documented source fields rather than comparing human-readable names alone.

Check whether the event belongs to the task currently selected for the lamp. A valid update from another project can still be irrelevant to that display. Record an ignored-task decision distinctly from an invalid event so later troubleshooting can explain why the colour stayed unchanged.

How can you determine which update is newer?

Use ordering or version information supplied by the source when it has documented semantics. A timestamp may help, but establish what it measures and how ties are handled. Local arrival time describes delivery, not necessarily when the underlying state became authoritative.

Where event payloads do not provide a reliable ordering rule, consider querying the source's current state before changing the display. That has its own availability and rate-limit requirements. If the current state cannot be established, retain uncertainty rather than selecting whichever event happened to arrive most recently.

What state should the receiver keep?

Store the accepted task identity, attempt and relevant version alongside the interpreted outcome. Make the comparison and update consistent when multiple workers can process events concurrently. Otherwise, both workers may read the same old value and write conflicting results in an unexpected order.

Preserve enough diagnostic information to explain accepted and rejected updates without retaining unnecessary payload data. GitHub's webhook guidance also covers delivery identifiers; identifying a duplicate delivery is useful, but it is not a substitute for ordering distinct events about one task.

How should the rule be tested?

Feed controlled events in normal order, reversed order and with an earlier attempt arriving late. Check the stored state before checking the physical output. Include concurrent processing if the real receiver uses several workers.

Send the resulting state through only the control interface confirmed for your unit. The Status Light hardware information describes the indicator; protection against stale overwrites belongs in the event-processing logic that decides what the lamp should mean.