[dependabot]

Bumps filelock from 3.32.3 to 4.2.4.

Release notes

Sourced from filelock's releases.

4.2.4

🐍 PyPI release

📜 Full Changelog

4.2.3

Bug fixes

• Creating a lock on a Python 3.15 interpreter without types.LazyImportType no longer triggers AttributeError at exit. #861 by @​gaborbernat.
• Handle EFTYPE when a no-follow open refuses a symlink in a soft reader/writer lock's protocol tree, so heartbeat reports lost ownership rather than a transient refresh error. #859 by @​edsonsims.

New Contributors

• @​edsonsims made their first contribution in #859

🐍 PyPI release

📜 Full Changelog

4.2.2

Bug fixes

• Fix a lock on a relative path that stayed held after a later with lock: ended, when an earlier acquire() had failed because the working directory no longer exists. That call still raises FileNotFoundError, and it now leaves the lock's hold count unchanged. #856 by @​spicysharkco.

New Contributors

• @​spicysharkco made their first contribution in #856

🐍 PyPI release

📜 Full Changelog

4.2.1

Bug fixes

• On a singleton wrapper, AsyncReadWriteLock.close() and AsyncSoftReadWriteLock.close() end only the holds that tasks acquired through that wrapper. A reader that arrives during close() gets the closed error instead of joining the ending hold. After synchronous code closes or force-releases the shared lock, the wrappers refuse to admit readers into the ended hold, and close() on such a wrapper returns. Closing one wrapper no longer ends a task's nested hold taken through another wrapper on the same path. #832 by @​gaborbernat.
• ReadWriteLock locks again after a release() that an exception from a signal handler interrupted. The async read-write wrappers stop admitting readers into such a level. The async read-write locks forget a hold whose backend release failed after the backend let go, and they free the memory of each acquire that times out or is canceled. AsyncFileLock returns from release() after a few hundred acquires gave up behind a waiting one. An exception from a signal handler delivered while an AsyncFileLock call joins its queue no longer blocks every later call on that lock. #833 by @​gaborbernat.
• Fix ReadWriteLock acting on -journal, -wal or -shm files another process puts beside its database: a write could land in another file, a reader could get in beside a writer, and an acquire could fail. SQLite now opens the database by name only in a directory no other account can write, and through a private hard link elsewhere. On Windows the directory's access control list decides. Where hard links are unavailable, keep the database in a directory other accounts cannot write, such as one under %LOCALAPPDATA%. The lock removes link directories through a checked descriptor rather than by name, reads a link directory's name only when the locking account owns it, and leaves alone a directory with other content renamed onto a link directory's name. A database whose schema takes more than a few kilobytes to load raises ValueError instead of running past the acquire timeout. #834 by @​gaborbernat.
• Fix five bugs in opening the lock file. UnixFileLock no longer truncates a file it did not create, such as one renamed to the lock path, and no longer applies mode to it. An on_acquired hook that writes holder metadata now truncates the file itself. A lease (Linux) or an oplock (Windows) on the lock file or a soft lock's marker no longer holds acquire() past its timeout or blocking=False, and an oplock no longer holds release(); ReadWriteLock on Windows waits for its timeout and raises Timeout. On Windows, a mode without group and other bits, such as 0o600, now creates the lock file with an owner-only permission list; the ReadWriteLock database gets the same. The soft locks' writability check no longer follows a symlink swapped in at the lock path. On a filesystem without flock, a contender from another account now waits on a marker it cannot write instead of raising PermissionError. #835 by @​gaborbernat.
• Fix SoftFileLock, MarkerSoftFileLock and SoftFileLease removing a live holder's marker in three cases: the holder and the contender run in Linux time namespaces with different boottime offsets; only one of them can read the boot id; a process other than the owner rewrote the marker. Soft markers no longer carry group or other write bits. A process name containing a carriage return or another line separator no longer makes the stale check raise ValueError. When /proc/self/ns/time exists but cannot be read, the stale check no longer compares start times and keeps the marker. #836 by @​gaborbernat.
• The async read-write locks record their hold under a task owner, so synchronous code on the executor thread that took the hold can no longer re-enter or release it. AsyncSoftReadWriteLock gives back one level on release, so synchronous readers of a shared singleton keep theirs. SoftReadWriteLock tracks read levels per thread: release() from a thread that holds none raises RuntimeError. After its heartbeat recorded a lost hold, it refuses new acquires until that hold is released. #838 by @​gaborbernat.
• StrictSoftFileLock creates <path>.filelock and its claims directory with the lock's mode and sets the sticky bit (a directory flag that lets only a file's owner remove it) on both. On the next acquisition it narrows a directory it owns that an earlier release created wider; it leaves a directory of another account as it is, so remove such leftovers by hand. It reaches claims through a descriptor opened without following symlinks; on Windows it holds both directories open and refuses a junction (a directory that points at another directory). Under a sticky parent such as /tmp it refuses a coordination directory of another account, as SoftReadWriteLock does for <path>.rw. One read grace now covers a whole claim scan, a failed claim cleanup no longer leaves the sentinel descriptor open, and a non-regular node at a sentinel private-record name raises SoftFileLockProtocolError. On Windows, contenders read claims without blocking their owner's unlink. #839 by @​gaborbernat.
• Fix a lock reporting a hold the OS had dropped after a signal handler raised during acquire or release. A release that a signal handler cuts short after it has started now completes before the error propagates. A handler that acquires the lock its own thread is releasing now gets RuntimeError instead of a hold that stays held. The singleton cache no longer hands out an is_singleton=True lock or a ReadWriteLock whose finalizer is running, which released the new holder's lock. A signal during os.fork() no longer leaves the other threads blocked in their next lock call, and a fork from another thread no longer waits for a ReadWriteLock acquire on a busy database. #840 by @​gaborbernat.
• Fix a lock on a relative path locking a file in the directory the process changed to while the lock waited, and leaving its marker behind on release after such a change. The path resolved when an acquisition starts stays in use until the hold ends. An is_singleton=True lookup no longer returns a cached lock whose relative path now resolves to another file; a held lock still matches the file it holds. A rename of the lock's directory during a hold no longer leaves the marker behind or reports a false lease compromise, and a waiter no longer creates a second lock file in a directory that was renamed away. #841 by @​gaborbernat.

... (truncated)

Changelog

Sourced from filelock's changelog.

########### Changelog ###########

.. towncrier-draft-entries:: Unreleased

.. towncrier release notes start

.. _release-4-2-6:

---

4.2.6 (2026-10-31)

---

.. _release-4-2-6-fixed:

Fixed

• Fix a race in :class:~filelock.SoftFileLock, :class:~filelock.MarkerSoftFileLock and :class:~filelock.SoftFileLease when three or more contenders reclaim a dead marker. The race could strand a live holder's marker under a break name, leaving the lock unusable or admitting a second holder. Contenders now recheck the marker before exchanging names and unwind nested exchanges in order. If the filesystem refuses a return exchange, the contender leaves its marker at the lock path for later recovery (:pr:899) by :user:dxbjavid and :user:gaborbernat.

.. _release-4-2-5:

---

4.2.5 (2026-10-30)

---

.. _release-4-2-5-fixed:

Fixed

• :meth:~filelock.BaseFileLock.acquire and :meth:~filelock.BaseAsyncFileLock.acquire raise :class:TypeError for a blocking that is not a :class:bool, as the constructor and the blocking setter already do. A truthy value such as the string "false" used to count as True, so a call meant as a single attempt waited for the instance's timeout, and without a limit at the default -1 (:pr:870) by :user:simpleqt and :user:gaborbernat.
• A :class:~filelock.SoftFileLock acquisition whose first read of its new marker's identity failed reads it again before rolling back. On Windows the rollback could otherwise not recognize the marker it had created, and the empty marker it left blocked the path for every later acquisition, since no contender breaks an empty marker (:pr:869) by :user:simpleqt and :user:gaborbernat.
• A fork() child of a process holding a :class:~filelock.SoftFileLease starts from an unheld claim. It used to inherit the parent's token, last compromise and heartbeat, so :attr:~filelock.SoftFileLease.token and :attr:~filelock.SoftFileLease.compromise reported a claim the child never held while is_locked reported it unheld (:pr:868) by :user:dxbjavid and :user:gaborbernat.
• A nested acquire of a held :class:~filelock.FileLock or :class:~filelock.SoftFileLock no longer creates the lock

... (truncated)

Commits

• 22f0776 Release 4.2.4
• 9d278ed Document GitHub Release note cleanup (#863)
• 3c33798 🐛 fix(release): trim GitHub release notes (#862)
• e737924 Release 4.2.3
• 84dc80c 👷 ci: collect required checks (#857)
• cb8b57e fix(api): guard lazy import exit hook (#861)
• dd341ac Handle NetBSD EFTYPE for replaced soft-RW protocol directories (#859)
• db47f34 Release 4.2.2
• caaff8a fix(api): keep the hold count when the lock path cannot be resolved (#856)
• 60331bb Release 4.2.1
• 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)

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

Run configuration

• Source mode: Auto
• Repository: AOSSIE-Org/OpenVerifiableLLM
• Branch: main
• File: .coderabbit.yaml
• Commit: f42508c
• Layers: Repository YAML
• Review profile: ASSERTIVE
• Plan: Advanced
• Run ID: 53f265ae-03b1-4b10-b421-dea73a900812

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• Trigger review

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

Share

• X
• Mastodon
• Reddit
• LinkedIn

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	pypi/​filelock@​3.32.3 ⏵ 4.2.4		+31

View full report