Revix: Automating Naver SmartStore with Playwright by youngwoo leeRevix: Automating Naver SmartStore with Playwright by youngwoo lee

Revix: Automating Naver SmartStore with Playwright

youngwoo lee

youngwoo lee

The problem
Naver SmartStore has no public API for seller reviews. Revix needs to sign in as the seller, pull every review with rating, product, photos and buyer history, and later post replies — against a target that is undocumented and actively defends itself against automation.
What I built
A Playwright layer that drives QR login, CAPTCHA relay to the seller, two-factor prompts and full session lifecycle. Sessions are per-tenant and fail-closed: seller A can never resolve seller B's session, and a test guards that boundary. A coverage ledger records which calendar days were provably collected in full, so a gap gets backfilled instead of becoming a permanent hole. Fourteen background job modules on Redis/RQ handle session warmup, collection, backfill and reply posting.
The bug that taught me the most
QR logins succeeded, then died at a timeout about 30 seconds later. For weeks the theory was "the target detects automation and wipes the session," and mitigations shipped against it. The real cause: inside headless_shell, the NetworkService child process — which owns the cookie store — was crashing and restarting 31 seconds in. On a fresh profile there was nothing on disk to restore, so cookies went from ten to zero mid-flow while the renderer looked healthy. I found it by reading process ages, not logs: a child younger than its parent is a child that died and came back. The fix was one argument — run full Chromium.
A stall that never happened
A polling loop reported the page "still loading" for 25 seconds. Both checks were local cache reads, and the loop slept with time.sleep, which blocked the event pump that would have refreshed the cache. The values were stale, not slow. An alarming "32 of 38 sessions force-closed" metric was an artifact of the same broken polling.
What this means for your project
Automating a platform that does not want to be automated is mostly about honest instrumentation and fail-closed defaults. I have done this end to end: login flows, session storage, cookie lifecycle, retries, and the incident write-up afterward.
Timeline of the cookie bug: a child process younger than its parent is a child that died and came back.
Timeline of the cookie bug: a child process younger than its parent is a child that died and came back.
Stale cache reads plus a blocked event pump invented a stall — and an alarming metric — that did not exist.
Stale cache reads plus a blocked event pump invented a stall — and an alarming metric — that did not exist.
Like this project

Posted Aug 25, 2026

QR login, CAPTCHA relay, 2FA and session lifecycle against an undocumented target. Found a weeks-old "cookie bug" was really a crashing Chromium child process.