๐๐ผ๐ผ๐ธ๐ถ๐ฒ ๐๐ ๐ฆ๐ฒ๐๐๐ถ๐ผ๐ป ๐๐ ๐๐ฟ๐ผ๐๐๐ฒ๐ฟ ๐ฃ๐ฟ๐ผ๐ณ๐ถ๐น๐ฒ
A browser automation task can fail even when the cookie is present.
This sounds strange until you debug a real workflow. Your script opens the right site, but the page asks for a login again. Or, it loads successfully inside the wrong workspace or account.
Most people blame an expired cookie. That is often wrong.
Cookies, sessions, and browser profiles are not the same. If you treat them as interchangeable, your automation will fail in production.
Use this debugging model:
- A cookie is browser-side request state.
- A session is the server-side trust relationship.
- A browser profile is the full environment. This includes cookies, local storage, IndexedDB, extensions, proxies, and timezones.
In Playwright, saving storage state with auth.json is useful. But an auth.json file is only part of the environment. It does not prove the server still trusts the session. It also does not prove you are using the right proxy or profile for the specific account.
A cookie can exist while the session behind it is dead. This happens when:
- The server expires the session.
- The account password changes.
- The site invalidates old sessions.
- The app expects local storage or IndexedDB state.
- The request comes from a different proxy or region.
Stop asking: "Do I have the cookie?" Start asking: "Does the application still accept this browser as a trusted session?"
The server gets a vote. You can preserve browser state, but you cannot force the server to accept it forever.
A session may depend on things your script does not capture:
- Recent login history.
- Account risk checks.
- IP or region consistency.
- MFA or verification status.
This is why a saved state file can be valid JSON but operationally dead.
To fix this, design a session lifecycle. Track when the auth state was created, which account used it, and when it must refresh.
Also, watch out for the "Wrong Account" failure. This is dangerous. The task does not fail, but it runs in the wrong context.
Never just check if a user is logged in. Check the visible account identity before you perform sensitive actions. Verify the email, workspace, and role on the page.
A good automation workflow follows this hierarchy:
- Cookies: Help the browser remember.
- Sessions: Decide if the server trusts that memory.
- Browser Profiles: Ensure the automation runs in the right environment.
Real automation breaks when these three drift apart.