A browser procedure can remain useful while the page around it changes. The challenge is deciding which changes are harmless and which make reuse unsafe. Cache invalidation should follow the procedure’s assumptions rather than an arbitrary confidence in yesterday’s successful run.
Define the assumptions of a saved step
Identify the website, account context, intended control and expected page condition. A button label alone may not be sufficient when a page contains several identical controls. Keep the context that distinguishes the intended target.
Separate procedure validity from data freshness. A navigation step may still work after a report changes, while a cached report result may already be stale. Expiring both together can waste useful knowledge; keeping both forever can return wrong data.
Validate before and after execution
Before using a step, check that its expected conditions hold and that the action is permitted. After execution, check a result that belongs to the task. A click returning without an error is weaker evidence than arriving at the correct report or observing the intended state.
Validation has a cost. Include it in the warm-path measurement and compare it with the planning work avoided. Skipping checks may improve a timing chart while increasing the amount of manual recovery needed.
Handle uncertainty differently from a clean miss
A miss before any action occurs can safely lead to planning. An uncertain result after a submission needs investigation. Look for a receipt, a changed status or another reliable signal before repeating the action.
In particular, do not treat a timeout as proof that a purchase, message or edit failed. Repeating a consequential operation can create a second effect. Where the target service supports it, use an idempotency mechanism appropriate to that operation.
Repair narrowly and test the revision
Capture a sanitized failure category and the smallest useful evidence. Relearn the changed step, then test the revised procedure with a low-impact case. Update its version so the old assumption is not silently mixed with the new one.
Measure invalidation and repair rates by workflow. An automation that frequently changes may benefit less from reuse than a stable internal tool. That does not make caching useless; it tells you where validation effort and maintenance cost belong in the economics.
Classify a failure before choosing a retry
Use three explicit outcomes: precondition mismatch before input, confirmed action failure, and action outcome unknown. The first can trigger fresh planning. The second needs the site’s failure evidence. The third needs reconciliation before another input. In a test fixture, interrupt a submission after the browser sends it and verify that recovery checks the resulting state rather than submitting twice. An idempotency token helps only when the destination actually honors it.