fix(token): Implement locking for token refresh

[solracsf]

Fix #1175

Added locking mechanism to prevent race conditions during token refresh.
Enhanced error handling and logging for token refresh process.

The fix uses ILockingProvider to ensure atomic token refresh:​

1. Per-session locking (prevents race within same user's requests)
2. First request acquires lock and refreshes token successfully, or,
3. a second request hits lock and waits 100ms, retries in loop (for 5 seconds max), then reads the already-refreshed token from session

[julien-nc]

Thank you very much. Code looks good. A few questions then I'll make some tests and we're good to go.

[solracsf]

You're right. The token refresh involves network requests to the OAuth2 provider, which typically takes 200-500ms or more. The 100ms wait was pointless because Process A will still be in the middle of the HTTP call...

I've pushed a retry mechanism to accomplish this :

Process A:

• Gets lock immediately
• Refreshes token (network request takes 300ms)
• Stores new token in session
• Releases lock

Process B:

• Tries to get lock, but get LockedException
• Waits 100ms, retries, waits, retries, acquires lock (A released it)
• Double-checks session, but Token already fresh
• Returns cached token without making redundant HTTP request
• Releases lock

This (should) prevent both the race condition and unnecessary duplicate token refreshes.

[solracsf]

I've just found out that this is a bit of a duplicate of #1178 but with another approach... sorry! 🙈

[julien-nc]

Please don't be sorry. I'm really not sure writing a lock in the Php session is a viable solution because I don't exactly know when Symfony reads and writes the session data. So we might get outdated data when reading the lock. Using the lock mechanism like you did + the session ID as identifier seems like a better approach.

[julien-nc]

Wdyt?

[julien-nc]

👍 💙