[BUGFIX] Keep the site running if the Redis server is unavailable

[bmack]

Fixes #34, fixes #27.

Problem

The Redis connection is established in the constructor (connectBackend()), and a RedisException thrown there is not caught. Core does not cushion that either: LockFactory::createLocker() instantiates the highest-priority strategy with new — no try/catch, no fallback to the next strategy — and it is called via ResourceMutex in the PrepareTypoScriptFrontendRendering middleware. A Redis outage therefore takes down the whole frontend with a 503, which is what happened in #34.

The same applies when the connection breaks while a request is running: lock() then returns false, the non-blocking acquire() throws LockAcquireWouldBlockException, and ResourceMutex keeps polling until max_execution_time is hit.

Solution

Connection problems are logged and handled by a fallback locking strategy instead of ending the request:

• gracefulDegradation (bool, default true) — survive an unavailable Redis server. Set to false for the previous behaviour, which now throws a LockCreateException instead of a raw RedisException.
• fallbackStrategy (class name, default TYPO3\CMS\Core\Locking\FileLockStrategy) — the strategy used while Redis is unavailable. Set to null to run without any locking in that case: the same page may then be generated by several processes in parallel, which is still better than a broken website. The same happens if the configured fallback strategy itself cannot be created.
• An unreachable server is not contacted again for 30 seconds within the same PHP process, so a request does not run into the connection timeout for every single lock it creates.
• Degradation also happens when the connection breaks mid-request (lock(), wait(), unlockAndSignal()), not only on connect.

While at it: the logger is fetched lazily, because LockFactory instantiates locking strategies via new instead of makeInstance(), so the logger is never injected and logging a Redis problem ended in "Call to a member function critical() on null" (#27).

The README documents the new options, the behaviour on an outage and the previously undocumented connectionTimeout / persistentConnection options.

Verification

Manually, against a TYPO3 v13 installation with phpredis 6.3 / PHP 8.5:

• Redis available: lock is acquired, a second locker for the same subject is blocked, release works (unchanged behaviour).
• Redis down, default fallback: no exception, the file lock is used and blocks a second locker.
• Redis down, fallbackStrategy => null: no exception, locking is skipped.
• Redis down, gracefulDegradation => false: LockCreateException.
• Redis goes away after a successful connect: the locker degrades to the fallback instead of throwing.
• Circuit breaker: 20 lockers created in under 100 ms after the first failed connection instead of waiting for the timeout each time.

[mschwemer]

@bmack Tested it in a customer environment using fallbackStrategy = null. Worked perfectly.

Thanks!

[bmack]

@copilot resolve the merge conflicts in this pull request

[Copilot]

@copilot resolve the merge conflicts in this pull request

Resolved by merging main into this branch and fixing the conflict in src/RedisLockingStrategy.php in commit 4e93b7d.