How to Prevent Exact-Count Automation From Overshooting

Suppose a task requests five reactions. The automation clicks the first item, but the page does not expose a confirmation signal quickly enough. If the workflow immediately moves to the next item, the first action may still succeed later. The final report can show four confirmed reactions while the account actually made five or six.

The fix is a side-effect-aware retry policy:

1. Retry when no action was taken.
2. Count only confirmed state changes.
3. Stop after an action whose result is unresolved.
4. Resume only after independent verification resolves the uncertainty.

This policy sacrifices a little apparent completion rate in exchange for exactness. In production operations, that trade is usually correct: a visible shortage with a precise reason is safer than a hidden overshoot.