What's the best way to handle 'state' parameter errors with social providers?

Alright, I've hit this issue enough times across different CI/CD pipelines that integrate with Auth0 for automation and testing that I need to vent and also get the community's take.

We're using Auth0 as our identity provider, and for many of our internal tools and staging environments, we rely heavily on social logins (Google, GitHub) for developer convenience. The problem is the infamous **"state" parameter error** — `invalid state parameter, state missing from store` — that pops up intermittently during the callback phase. It's a total pipeline killer when you're trying to automate something that requires authentication.

From my digging, I know the `state` parameter is crucial for CSRF protection. Auth0 generates it, stores it in a session, and validates it on callback. The failures seem to happen when:
* The session store isn't properly configured or is misbehaving (e.g., using default in-memory store in a multi-instance setup).
* There's a time delay or a race condition in the flow.
* The callback URL is hit without the proper session context (happens a lot in headless automation).

I've tried a few mitigations with varying success:

* **Tweaking Auth0's `SESSION_COOKIE` settings** in the tenant, playing with `mode` and `persistence`. This feels like a black box.
* **Implementing a custom `state` generation** in our app's Auth0 SDK integration, trying to make it deterministic for testing, but that seems to undermine the security purpose.
* For CI, we sometimes **bypass social login entirely** for non-interactive flows using Resource Owner Password Grant (not recommended and not even available for all social connections) or a direct API approach, which is messy.

What's the **robust, production-ready way** to squash this? I'm especially interested in patterns that work in:

* **Containerized environments** where the Auth0 callback might hit different instances.
* **CI/CD workers** (like GitHub Actions runners) that need to programmatically complete a social login flow for e2e tests.

Is it all about the session store? Should we be using a distributed store like Redis for the Auth0 session? If so, what's the config look like? Or is there a way to reliably validate/ignore `state` for specific, trusted callback URLs (feels dangerous)?

Here's a snippet of the kind of error handling we're drowning in right now in our test pipelines:

```javascript
// Puppeteer script trying to authenticate
try {
await page.click('[href="/login/auth0?connection=google-oauth2"]');
// ... fill social login...
await page.waitForNavigation();
} catch (err) {
if (err.message.includes('state')) {
// Retry logic, but it's flaky.
console.error('State parameter failure. Re-initiating flow.');
await page.goto(process.env.APP_URL + '/login?retry=true');
}
}
```

This is clearly not the way. What are your battle-tested solutions? Let's get into the weeds on this one.