Repository navigation
Pro profiles: capture after Firefox lets go of the profile - #16
Conversation
A persistent context's "close" event fires while Firefox is still writing prefs.js and places.sqlite on its way out. The state sync it triggers read those files mid-write and gave up with "changed size after capture", so a profile's state never reached the server. The sync now waits until Firefox releases the profile lock (the lock symlink's process, or parent.lock on Windows) before capturing. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
❌ Tests failedCamoufox
What failed
The Playwright suite is upstream playwright-python at the tag above, fetched fresh, with |
✅ Tests passedCamoufox
The Playwright suite is upstream playwright-python at the tag above, fetched fresh, with |
Closing a Pro profile's browser never synced its state. Both sessions of FlashCollection's live test logged:
attachLease(lease, context, "close")starts the sync on the persistent context'scloseevent, which Playwright emits while Firefox is still flushing those files during shutdown. The capture read them mid-write, the size check rightly refused it, and the session was parked inpending/.onClosenow waits for Firefox to release the profile before capturing: on Linux/macOS until the process named by thelocksymlink (<address>:+<pid>) has exited, on Windows untilparent.lockcan be opened. A stale lock from a crash is ignored. If it times out (30 s) the size check still refuses a moving file and the session is kept for the next launch, as before.Tests: the wait lasts exactly until a real lock-holding process exits; a stale or absent lock returns at once. Full TS suite 822 passed, biome and tsc clean. The Windows branch is not exercised by CI here.
🤖 Generated with Claude Code