build(deps): Update portalocker requirement from >=3.2.0 to >=4.2.0

[dependabot]

Updates the requirements on portalocker to permit the latest version.

Release notes

Sourced from portalocker's releases.

v4.2.0

4.2.0:

• Connection policy change: the RedisLock subscription now lives on a dedicated connection that never retries and never reconnects (retry=Retry(NoBackoff(), 0, supported_errors=()), holder name set at the connection level, RESP2 with maintenance notifications disabled), derived per attempt from the command connection's pool and inheriting that connection's health_check_interval (a supplied connection left at the redis-py default of 0 therefore gets no health-check ping on the subscription either, so a silently partitioned link is only noticed through the socket, as the module documentation has always advised setting it). Previously a killed or dropped holder connection was silently resurrected by redis-py's retry machinery: the holder resubscribed without its name, kept believing it held the lock while the channel had already released it, inflated the subscriber count, and could never be reaped again, permanently blocking exclusive acquisition. Holders on flaky networks now lose their locks loudly instead of keeping them incorrectly, which is the correctness fix. The command connection keeps its default retry policy, and waiter-side blips still only cost one acquire attempt. Exotic setups (Sentinel, cluster, custom pools) can supply the new subscription_connection_factory parameter. Note that under redis-py's default socket_timeout of five seconds a read stalled that long now counts as a loss, and that a pre-4.2 holder on the same channel still resubscribes silently when killed, so the guarantee covers a channel once every participant runs 4.2+ (#137)
• Added loss surfacing to RedisLock: a new portalocker.LockLostError (carrying channel, holder_id and the causal exception as __cause__), a lost property, an ensure_held() check for long critical sections, an on_lost callback invoked exactly once per loss on the keep-alive thread, and a with block exit that raises LockLostError after releasing when the body finished cleanly. release() never raises on account of a loss and leaves the loss observable; acquire() on a lost instance resets it (#137, #141)
• Scoped RedisLock worker failures to what actually failed: a waiter whose subscription dies retries within its timeout budget with no process-wide interrupt, while a held lock's worker death marks the lock lost, and the escalation now catches BaseException (a SystemExit or KeyboardInterrupt landing on the worker no longer dies silently). The main-thread interrupt is governed by the new interrupt_on_lost parameter, defaulting to True in 4.2 with a DeprecationWarning at loss time when left unset; portalocker 5.0.0 flips the default to False. Acquisition success is confirmed against the worker's state under a lock, so a subscription dying between the winning probe and the bookkeeping costs one attempt instead of producing an imaginary hold (#141)

... (truncated)

Changelog

Sourced from portalocker's changelog.

4.2.0:

• Connection policy change: the RedisLock subscription now lives on a dedicated connection that never retries and never reconnects (retry=Retry(NoBackoff(), 0, supported_errors=()), holder name set at the connection level, RESP2 with maintenance notifications disabled), derived per attempt from the command connection's pool and inheriting that connection's health_check_interval (a supplied connection left at the redis-py default of 0 therefore gets no health-check ping on the subscription either, so a silently partitioned link is only noticed through the socket, as the module documentation has always advised setting it). Previously a killed or dropped holder connection was silently resurrected by redis-py's retry machinery: the holder resubscribed without its name, kept believing it held the lock while the channel had already released it, inflated the subscriber count, and could never be reaped again, permanently blocking exclusive acquisition. Holders on flaky networks now lose their locks loudly instead of keeping them incorrectly, which is the correctness fix. The command connection keeps its default retry policy, and waiter-side blips still only cost one acquire attempt. Exotic setups (Sentinel, cluster, custom pools) can supply the new subscription_connection_factory parameter. Note that under redis-py's default socket_timeout of five seconds a read stalled that long now counts as a loss, and that a pre-4.2 holder on the same channel still resubscribes silently when killed, so the guarantee covers a channel once every participant runs 4.2+ (#137)
• Added loss surfacing to RedisLock: a new portalocker.LockLostError (carrying channel, holder_id and the causal exception as __cause__), a lost property, an ensure_held() check for long critical sections, an on_lost callback invoked exactly once per loss on the keep-alive thread, and a with block exit that raises LockLostError after releasing when the body finished cleanly. release() never raises on account of a loss and leaves the loss observable; acquire() on a lost instance resets it (#137, #141)
• Scoped RedisLock worker failures to what actually failed: a waiter whose subscription dies retries within its timeout budget with no process-wide interrupt, while a held lock's worker death marks the lock lost, and the escalation now catches BaseException (a SystemExit or KeyboardInterrupt landing on the worker no longer dies silently). The main-thread interrupt is governed by the new interrupt_on_lost parameter, defaulting to True in 4.2 with a DeprecationWarning at loss time when left unset; portalocker 5.0.0 flips the default to False. Acquisition success is confirmed against the worker's state under a lock, so a subscription dying between the winning probe and the bookkeeping costs one attempt instead of producing an imaginary hold (#141)
• Made RedisLock teardown fork safe: a forked child inheriting a

... (truncated)

Commits

• 86cf1ac bumped the version to 4.2.0 and folded the unreleased 4.1.1 section into it
• d5e5608 gave the healthy self-check test a CI-proof interval and satisfied codespell
• 7e13d28 added the opt-in self-check heartbeat and fencing tokens (#146)
• 5d7a3b3 honoured the confirm probe verifier's documentation notes (#145)
• 11a3a2a closed the fast-path reply-staleness double-exclusive window with a confirm p...
• b774708 version forked the release-note assertion for python 3.10
• 00a26b2 covered the handler-less read loop raise and satisfied ty on the probe-error ...
• d91921d brought the stale escalation, changelog and loss-detection notes up to the sh...
• 3c3546e rolled a bounded semaphore slot back when an interrupt lands before or at pub...
• d682472 made the redis block exit read the loss after release and keep the body excep...
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)