𝗥𝗲𝗰𝗼𝘃𝗲𝗿𝗶𝗻𝗴 𝗦𝘁𝗮𝗹𝗲 𝗕𝗿𝗼𝘄𝘀𝗲𝗿 𝗣𝗿𝗼𝗳𝗶𝗹𝗲 𝗟𝗼𝗰𝗸𝘀
A browser profile lock prevents two workers from opening the same account at once.
Most automation systems fail during recovery. When a worker crashes or loses network, the system sees an old lock and deletes it. This makes the queue move, but it corrupts your account state.
A stale lock is not a file to delete. It is an unfinished operation that needs a controlled recovery path.
Stop treating locks as simple files. Treat them as leases.
A safe lease needs:
- An owner
- An expiry time
- A heartbeat
- A version number (fencing token)
The version number is vital. Every write must include the latest token. If an old worker returns after a new worker takes over, the system rejects the old token. This prevents silent corruption.
Do not jump from locked to available. Use a state machine to move through these stages:
- Held
- Suspected stale
- Quarantined
- Inspected
- Available | Resume pending | Manual review
The quarantine stage is critical. It stops a second worker from touching the profile while you investigate.
During investigation, you must collect evidence:
- Was the browser process still running?
- What was the last known URL?
- Was the task in a sensitive step like checkout or settings changes?
- Is there a screenshot of the failure?
If a task stopped during a sensitive operation, do not auto-resume. Send it to manual review. Automation should have boundaries to prevent bad decisions.
Common mistakes to avoid:
- Deleting the lock without checking the profile safety.
- Not using fencing tokens to reject late writes from old workers.
- Retrying form submissions without a known safe checkpoint.
- Changing proxies during the recovery process.
The goal is not to make recovery complex. The goal is to make it explicit.
A lock is just a symptom. Your system must protect the account environment behind that lock.
One profile. One owner lease. One active task. One evidence trail. One recovery decision.