[dependabot]

Bumps filelock from 3.32.4 to 4.2.1.

Release notes

Sourced from filelock's releases.

4.2.1

Security

This release fixes the following vulnerabilities:

• CVE-2026-112940 (high): ReadWriteLock: SQLite reopens the lock database by name, so a planted symlink or journal file makes the lock user's process overwrite or unlink its own files.
• CVE-2026-112906 (medium): SoftFileLock evicts a fresh lock file whose watched age another local user's pre-dated file passed on through inode reuse.
• CVE-2026-112908 (medium): StrictSoftFileLock creates its claim directories without the lock mode, so another local user with a write bit on them can end a live hold.
• CVE-2026-112909 (medium): UnixFileLock truncates and chmods any regular file another user renames or hard-links onto the lock path.
• CVE-2026-112910 (medium): WindowsFileLock ignores mode: a 0o600 lock file and the ReadWriteLock database inherit the directory ACL.
• CVE-2026-112911 (medium): StrictSoftFileLock and SoftReadWriteLock adopt a protocol directory another user created first, losing mutual exclusion.
• CVE-2026-112914 (medium): SoftFileLock stale-break restore follows a swapped-in symbolic link and hard-links a file of the user running the lock into the lock directory.
• CVE-2026-112915 (medium): ReadWriteLock: a crafted lock database makes every acquire stall or hang regardless of timeout.
• CVE-2026-112934 (medium): SoftReadWriteLock holder refresh writes through a hard link and hangs on a named pipe that another local user renames over its record.
• CVE-2026-112935 (medium): SoftFileLock stale-lock break removes a live lock file on a reused inode number and admits two holders.
• CVE-2026-112937 (medium): ReadWriteLock on the hard-link route deletes any directory another user renames onto its .filelock-* link directory name.
• CVE-2026-112938 (medium): StrictSoftFileLock follows a symbolic link swapped in at .filelock and creates claim files in a directory another local user chooses.
• CVE-2026-112939 (medium): SoftFileLock removes a live holder's marker when another user forges the PID in a writable marker.
• CVE-2026-112907 (low): On Windows an oplock on a soft lock's marker holds SoftFileLock.acquire() past its timeout and blocks the stale break.
• CVE-2026-112912 (low): Symlink swap during SoftFileLock's writability check leaks whether a path exists and is writable by the lock taker.
• CVE-2026-112913 (low): ReadWriteLock on Windows acts on SQLite side files another local user places beside its database.
• CVE-2026-112941 (low): SoftReadWriteLock follows a lock tree swapped in after its first acquire and writes lock records into directories of the user running the lock.

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.
• SoftReadWriteLock reaches its records through descriptors of <path>.rw and gen or holders opened without following symlinks. On Windows it holds those directories open and refuses a junction (a directory that points at another directory). A tree swapped in after an earlier acquire therefore cannot redirect them. Its heartbeat rewrites a holder record only when the name still leads to the file it created, and does not block on a FIFO (a named pipe). A heartbeat that finds <path>.rw replaced by a symlink or junction reports the hold lost instead of ending the heartbeat thread. A live lock object repeats the ownership check whenever the tree it opens is not the one it prepared. #842 by @​gaborbernat.
• Fix SoftFileLock, MarkerSoftFileLock and SoftFileLease removing or displacing a live holder's marker in five cases. ext4 gave a freed inode number to the next marker. A stalled FileLock removed its ENOSYS placeholder after a peer replaced it. A failed acquire cleaned up after a successor took the path. A stale break left the lock path empty while it checked the marker it had moved. A lifetime break judged a marker by a reused inode number. On Linux and macOS a stale marker now changes hands in one atomic exchange. On other platforms without one, except Windows, including NFS and SMB, the marker stays in place and waits for timeout or break_lock(). Restoring a marker no longer follows a symlink found under the break name. A holder that releases while a peer's exchange has its marker aside leaves a record no lock parses, so the put-back lands a marker that ages out. A lease heartbeat that finds another file at the lock path once, while a peer's break has its marker aside, waits for the next refresh before it reports a compromise. A contender that finds a dead breaker's marker puts back the marker that breaker left under its break name. A marker is the breaker's own only when it names the breaker's process on this host; the same process number on another host is a holder. A contender takes a stranded marker under a name of its own before it puts the marker back, so two contenders no longer reverse each other's exchange and remove the live holder's marker. A claim left behind by a failed put-back is retried on the next poll. #843 by @​gaborbernat.
• Canceling an AsyncReadWriteLock or AsyncSoftReadWriteLock acquire that waits for another process now stops the wait and raises the cancellation. It used to wait until that process released, or raise Timeout. A thread_local=True AsyncFileLock that threads with their own event loops share no longer deadlocks when one thread waits for the lock while another holds it. #844 by @​gaborbernat.
• SoftReadWriteLock refuses a commit that lands a whole retention window behind the log, so two committers stalled at adjacent generations can no longer admit a second writer. Its stale check samples the clock before it reads a holder record, so a pause between the two no longer counts as time the record stayed unchanged. #845 by @​gaborbernat.
• Fix a SoftFileLock contender evicting an empty marker after two seconds while its owner held the lock. The owner is a SoftFileLock before 3.22, which writes nothing into its marker, or a current one still writing its record. An empty marker now reads as held, and timeout, lifetime or break_lock() clears it. A contender that finds an empty marker a dead breaker left aside puts it back instead of removing it. #846 by @​gaborbernat.
• Fix ReadWriteLock on Windows acting on -journal and -wal files another account places beside its database: an acquire could fail with OperationalError, or SQLite could replay the journal and delete the file it names. The lock now reads the database directory's access control list. Where an account other than the locking account, SYSTEM and Administrators can add or remove names, SQLite opens a hard link inside a directory only those accounts can write. A filesystem without hard links raises OSError. #854 by @​gaborbernat.
• Fix SoftReadWriteLock subclasses sharing singleton instances with the base class or sibling subclasses. Each concrete class now keeps its own cache and construction guard, including after fork, while preserving cooperative class-definition keywords. #855 by @​AryanRG.

New Contributors

• @​AryanRG made their first contribution in #855

... (truncated)

Changelog

Sourced from filelock's changelog.

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

.. towncrier-draft-entries:: Unreleased

.. towncrier release notes start

.. _release-4-2-9:

---

4.2.9 (2026-11-04)

---

.. _release-4-2-9-fixed:

Fixed

• :class:~filelock.ReadWriteLock, :class:~filelock.SoftReadWriteLock and their async wrappers now raise :class:TypeError for a blocking that is not a :class:bool, in the constructor and on acquire, as :class:~filelock.FileLock already does. Before, blocking=0 waited out the full timeout on a contended :class:~filelock.ReadWriteLock while blocking=False failed at once, and a truthy value such as "false" turned a single attempt into a blocking wait (:pr:908) by :user:abhishekcpp007 and :user:gaborbernat.

.. _release-4-2-8:

---

4.2.8 (2026-11-04)

---

.. _release-4-2-8-documentation:

Documentation

• Clarify the platform-specific locking primitive and range used by descriptor locks, and correct the guidance on interoperating with byte-range lock protocols such as conda's repodata lock (:pr:905) by :user:boyfeiyu.

.. _release-4-2-7:

---

4.2.7 (2026-11-02)

---

.. _release-4-2-7-fixed:

Fixed

... (truncated)

Commits

• 60331bb Release 4.2.1
• 834bf13 🧪 test(soft): skip Unix pin test on Windows
• 9d15e38 fix(soft-rw): isolate subclass singleton registries (#855)
• e1e825b 🐛 fix(open): keep lock files intact, honor deadlines and mode (#835)
• 5e3f2ec 🐛 fix(read-write): keep SQLite off shared names, bound schema (#834)
• bfa066d 🐛 fix(strict): keep claim directories private to the lock (#839)
• 977d2c3 🐛 fix(soft): wait on an empty marker instead of evicting (#846)
• 740ff66 🐛 fix(soft): break stale markers without emptying the lock path (#843)
• 86c6d5f 🐛 fix(async): honor cancellation and per-thread gates (#844)
• eeceaa8 🐛 fix(soft): keep live holders when owner identity differs (#836)
• 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)
  You can disable automated security fix PRs for this repo from the Security Alerts page.

[github-actions]

posthog-python Compliance Report

Date: 2026-11-05T23:55:54.207431+00:00
Duration: 260110ms

✅ All Tests Passed!

121/121 tests passed

---

Capture_V1 Tests

✅ 95/95 tests passed

View Details

Test	Status	Duration
Endpoint And Method.Targets V1 Endpoint	✅	517ms
Endpoint And Method.Does Not Use Legacy Endpoints	✅	513ms
Required Headers.Has Authorization Bearer Header	✅	512ms
Required Headers.Has Content Type Json	✅	511ms
Required Headers.Has Posthog Sdk Info Format	✅	513ms
Required Headers.Has Posthog Attempt Header	✅	513ms
Required Headers.Has Posthog Request Id	✅	513ms
Required Headers.Has Posthog Request Timestamp	✅	512ms
Required Headers.Has User Agent	✅	513ms
Body Format.Body Has Created At And Batch	✅	512ms
Body Format.No Api Key In Body	✅	512ms
Body Format.No Sent At In Body	✅	512ms
Event Format.Event Has Required Root Fields	✅	511ms
Event Format.Event Uuid Is Valid	✅	512ms
Event Format.Event Timestamp Is Rfc3339	✅	512ms
Event Format.Non Utc Event Timestamp Is Converted To Utc	✅	528ms
Event Format.Distinct Id Is String	✅	515ms
Event Format.Distinct Id At Root Not Properties	✅	512ms
Event Format.Custom Properties Preserved	✅	511ms
Event Format.Set Properties Preserved	✅	512ms
Event Format.Set Once Properties Preserved	✅	512ms
Event Format.Groups Properties Preserved	✅	512ms
Event Format.Sdk Generates Uuid If Not Provided	✅	512ms
Event Format.Event Has Required Root Fields Batch	✅	515ms
Event Format.Event Uuid Is Valid Batch	✅	516ms
Event Format.Event Timestamp Is Rfc3339 Batch	✅	515ms
Event Format.Distinct Id Is String Batch	✅	516ms
Event Format.Distinct Id At Root Not Properties Batch	✅	515ms
Event Format.Custom Properties Preserved Batch	✅	516ms
Event Format.Set Properties Preserved Batch	✅	517ms
Event Format.Set Once Properties Preserved Batch	✅	515ms
Event Format.Groups Properties Preserved Batch	✅	515ms
Event Format.Sdk Generates Uuid If Not Provided Batch	✅	516ms
Batch Behavior.Multiple Events In Single Batch	✅	519ms
Batch Behavior.Batch Envelope Smoke	✅	517ms
Batch Behavior.Flush With No Events Sends Nothing	✅	507ms
Batch Behavior.Flush At Triggers Batch	✅	1013ms
Batch Behavior.Created At Reflects Batch Creation Time	✅	512ms
Deduplication.Generates Unique Uuids	✅	519ms
Deduplication.Different Events Same Content Different Uuids	✅	514ms
Deduplication.Preserves Uuid On Retry	✅	6517ms
Deduplication.Preserves Timestamp On Retry	✅	6522ms
Deduplication.Preserves Uuid And Timestamp On Batch Retry	✅	6521ms
Deduplication.No Duplicate Events In Batch	✅	520ms
Header Behavior On Retry.Attempt Header Starts At One	✅	513ms
Header Behavior On Retry.Attempt Header Increments On Retry	✅	13525ms
Header Behavior On Retry.Request Id Preserved On Retry	✅	6520ms
Header Behavior On Retry.Different Requests Have Different Request Ids	✅	3020ms
Header Behavior On Retry.Request Timestamp Changes On Retry	✅	6518ms
Response Format Validation.Success Response Has Uuid Keyed Results	✅	511ms
Response Format Validation.Success Response Has Ok For Each Event	✅	516ms
Response Format Validation.Success No Retry After When All Ok	✅	514ms
Response Format Validation.Success Retry After Present When Retry Events	✅	1518ms
Response Format Validation.Success No Retry After When Drop Only	✅	514ms
Response Format Validation.Response Echoes Request Id	✅	511ms
Retry Behavior.Retries On 408	✅	6516ms
Retry Behavior.Retries On 500	✅	6521ms
Retry Behavior.Retries On 503	✅	8525ms
Retry Behavior.Retries On 504	✅	6520ms
Retry Behavior.Retryable Errors Have Retry After	✅	3524ms
Retry Behavior.Respects Retry After On Retryable Error	✅	11525ms
Retry Behavior.Does Not Retry On 400	✅	2515ms
Retry Behavior.Does Not Retry On 401	✅	2516ms
Retry Behavior.Does Not Retry On 402	✅	2515ms
Retry Behavior.Does Not Retry On 413	✅	2516ms
Retry Behavior.Does Not Retry On 415	✅	2516ms
Retry Behavior.Non Retryable Errors Have No Retry After	✅	2514ms
Retry Behavior.Implements Backoff	✅	22536ms
Retry Behavior.Max Retries Respected	✅	22523ms
Partial Batch Handling.Handles 200 Full Success	✅	2515ms
Partial Batch Handling.Handles 200 With All Ok	✅	3519ms
Partial Batch Handling.Does Not Retry Dropped Events	✅	3516ms
Partial Batch Handling.Does Not Retry Limited Events	✅	3516ms
Partial Batch Handling.Prunes Ok Events On Partial Retry	✅	6523ms
Partial Batch Handling.Prunes Dropped Events On Partial Retry	✅	6519ms
Partial Batch Handling.Retries Only Retry Events From Partial	✅	6524ms
Partial Batch Handling.Partial Retry Preserves Uuids	✅	6521ms
Partial Batch Handling.Partial Retry Attempt Header Increments	✅	6518ms
Partial Batch Handling.Partial Retry Request Id Preserved	✅	6519ms
Partial Batch Handling.Respects Retry After On Partial	✅	8518ms
Partial Batch Handling.Unknown Result Treated As Terminal	✅	3516ms
Partial Batch Handling.Mixed Ok Drop Limited No Retry	✅	3520ms
Compression.Sends Gzip Content Encoding	✅	512ms
Compression.No Content Encoding When Disabled	✅	511ms
Compression.Compressed Body Is Decompressible	✅	512ms
Error Handling.Does Not Retry On Unknown 4Xx	✅	2513ms
Event Options.Cookieless Mode Override	✅	513ms
Event Options.Disable Skew Correction Override	✅	511ms
Event Options.Process Person Profile Override	✅	511ms
Event Options.Product Tour Id Override	✅	512ms
Event Options.Unset Options Omitted	✅	510ms
Event Options.Options Override In Batch	✅	514ms
Geoip And Historical Migration.Geoip Disable Injected Into Properties	✅	511ms
Geoip And Historical Migration.Historical Migration Set In Body	✅	511ms
Geoip And Historical Migration.Historical Migration Absent By Default	✅	512ms

Capture_Ai Tests

✅ 5/5 tests passed

View Details

Test	Status	Duration
Routing.Capture Ai Posts To Ai Endpoint	✅	511ms
Routing.Capture Does Not Reroute Ai Named Events	✅	511ms
Identity.Capture Ai Event Has Uuid	✅	512ms
Identity.Capture Ai Keeps Supplied Uuid	✅	511ms
Timestamp Format.Non Utc Event Timestamp Is Converted To Utc	✅	512ms

Feature_Flags Tests

✅ 17/17 tests passed

View Details

Test	Status	Duration
Request Payload.Request With Person Properties Device Id	✅	12ms
Request Payload.Flags Request Uses V4 Query Param	✅	9ms
Request Payload.Flags Request Hits Flags Path Not Decide	✅	9ms
Request Payload.Flags Request Omits Authorization Header	✅	9ms
Request Payload.Token In Flags Body Matches Init	✅	9ms
Request Payload.Groups Round Trip	✅	8ms
Request Payload.Groups Default To Empty Object	✅	9ms
Request Payload.Disable Geoip False Propagates As Geoip Disable False	✅	9ms
Request Payload.Disable Geoip Omitted Defaults To False	✅	9ms
Request Payload.Flag Keys To Evaluate Contains Only Requested Key	✅	9ms
Request Lifecycle.No Flags Request On Init Alone	✅	3ms
Request Lifecycle.No Flags Request On Normal Capture	✅	508ms
Request Lifecycle.Two Flag Calls Produce Two Remote Requests	✅	15ms
Request Lifecycle.Mock Response Value Is Returned To Caller	✅	9ms
Retry Behavior.Retries Flags On 502	✅	314ms
Retry Behavior.Retries Flags On 504	✅	315ms
Side Effect Events.Get Feature Flag Captures Feature Flag Called Event	✅	511ms

Feature_Flags_Local_Evaluation Tests

✅ 4/4 tests passed

View Details

Test	Status	Duration
Versioned Boolean Matching.Matching Version Missing	✅	67ms
Versioned Boolean Matching.Matching Version 1	✅	63ms
Versioned Boolean Matching.Matching Version 2	✅	63ms
Versioned Boolean Matching.Version Only Reload 1 2 1 2 Missing	✅	35ms

[github-actions]

SDK performance: posthog-python

Benchmarks completed. No changes flagged for review.

Flags require at least a 5% change in the median and all six pairs agreeing on direction. This is a noise filter, not proof of a performance change or a CI gate.

View all results

Test	Measurement	Before PR	With PR	Change	Assessment
Capture and deliver events (32-byte payload, burst) Shard: capture	Managed heap after settling	—	—	—	unavailable; base:​ unsupported; head:​ unsupported; base:​ CPython has no uninstrumented total managed-heap byte counter; tracing would distort this RSS pass.​; head:​ CPython has no uninstrumented total managed-heap byte counter; tracing would distort this RSS pass.​
Capture and deliver events (4,096-byte payload, burst) Shard: capture	Managed heap after settling	—	—	—	unavailable; base:​ unsupported; head:​ unsupported; base:​ CPython has no uninstrumented total managed-heap byte counter; tracing would distort this RSS pass.​; head:​ CPython has no uninstrumented total managed-heap byte counter; tracing would distort this RSS pass.​
Capture and deliver events (32-byte payload, steady) Shard: capture	Managed heap after settling	—	—	—	unavailable; base:​ unsupported; head:​ unsupported; base:​ CPython has no uninstrumented total managed-heap byte counter; tracing would distort this RSS pass.​; head:​ CPython has no uninstrumented total managed-heap byte counter; tracing would distort this RSS pass.​
Capture and deliver events (4,096-byte payload, steady) Shard: capture	Managed heap after settling	—	—	—	unavailable; base:​ unsupported; head:​ unsupported; base:​ CPython has no uninstrumented total managed-heap byte counter; tracing would distort this RSS pass.​; head:​ CPython has no uninstrumented total managed-heap byte counter; tracing would distort this RSS pass.​
Queue an event (32-byte payload) Shard: capture	Allocated memory per operation	—	—	—	unavailable; base:​ unsupported; head:​ unsupported; base:​ Background preparation has no public completion boundary before flush; see capture.​drain for full-pipeline allocations.​; head:​ Background preparation has no public completion boundary before flush; see capture.​drain for full-pipeline allocations.​
Queue an event (32-byte payload) Shard: capture	Allocations per operation	—	—	—	unavailable; base:​ unsupported; head:​ unsupported; base:​ Background preparation has no public completion boundary before flush; see capture.​drain for full-pipeline allocations.​; head:​ Background preparation has no public completion boundary before flush; see capture.​drain for full-pipeline allocations.​
Queue an event (4,096-byte payload) Shard: capture	Allocated memory per operation	—	—	—	unavailable; base:​ unsupported; head:​ unsupported; base:​ Background preparation has no public completion boundary before flush; see capture.​drain for full-pipeline allocations.​; head:​ Background preparation has no public completion boundary before flush; see capture.​drain for full-pipeline allocations.​
Queue an event (4,096-byte payload) Shard: capture	Allocations per operation	—	—	—	unavailable; base:​ unsupported; head:​ unsupported; base:​ Background preparation has no public completion boundary before flush; see capture.​drain for full-pipeline allocations.​; head:​ Background preparation has no public completion boundary before flush; see capture.​drain for full-pipeline allocations.​
Evaluate 1,000 flags under concurrent load Shard: flags-memory	Managed heap after settling	—	—	—	unavailable; base:​ unsupported; head:​ unsupported; base:​ CPython has no uninstrumented total managed-heap byte counter; tracing would distort this RSS pass.​; head:​ CPython has no uninstrumented total managed-heap byte counter; tracing would distort this RSS pass.​
Refresh 1,000 flag definitions Shard: flags-memory	Managed heap after settling	—	—	—	unavailable; base:​ unsupported; head:​ unsupported; base:​ CPython has no uninstrumented total managed-heap byte counter; tracing would distort this RSS pass.​; head:​ CPython has no uninstrumented total managed-heap byte counter; tracing would distort this RSS pass.​
Capture and deliver events (32-byte payload, burst) Shard: capture	Allocated memory per operation	113.53 KiB/op	113.53 KiB/op	<0.1% less memory	Not flagged
Capture and deliver events (32-byte payload, burst) Shard: capture	Allocations per operation	1,096.56 count/op	1,096.55 count/op	<0.1% fewer	Not flagged
Capture and deliver events (32-byte payload, burst) Shard: capture	Time per operation	50.41 µs/op	52.28 µs/op	3.7% more time	Not flagged
Capture and deliver events (32-byte payload, burst) Shard: capture	Idle process memory (RSS)	36.02 MiB	36 MiB	<0.1% less memory	Not flagged
Capture and deliver events (32-byte payload, burst) Shard: capture	Observed peak process memory (RSS)	37.77 MiB	37.75 MiB	<0.1% less memory	Not flagged
Capture and deliver events (32-byte payload, burst) Shard: capture	Process memory after settling (RSS)	37.77 MiB	37.75 MiB	<0.1% less memory	Not flagged
Capture and deliver events (32-byte payload, burst) Shard: capture	Process CPU time per operation	51.73 µs/op	53.98 µs/op	4.4% more time	Not flagged
Capture and deliver events (32-byte payload, burst) Shard: capture	Lifetime peak process memory (RSS)	39.66 MiB	39.66 MiB	No observed change	Not flagged
Capture and deliver events (4,096-byte payload, burst) Shard: capture	Allocated memory per operation	166.1 KiB/op	166.1 KiB/op	<0.1% less memory	Not flagged
Capture and deliver events (4,096-byte payload, burst) Shard: capture	Allocations per operation	1,089.6 count/op	1,089.6 count/op	<0.1% more	Not flagged
Capture and deliver events (4,096-byte payload, burst) Shard: capture	Time per operation	68.69 µs/op	69.48 µs/op	1.1% more time	Not flagged
Capture and deliver events (4,096-byte payload, burst) Shard: capture	Idle process memory (RSS)	40.86 MiB	40.8 MiB	0.1% less memory	Not flagged
Capture and deliver events (4,096-byte payload, burst) Shard: capture	Observed peak process memory (RSS)	45.95 MiB	45.9 MiB	0.1% less memory	Not flagged
Capture and deliver events (4,096-byte payload, burst) Shard: capture	Process memory after settling (RSS)	45.95 MiB	45.9 MiB	0.1% less memory	Not flagged
Capture and deliver events (4,096-byte payload, burst) Shard: capture	Process CPU time per operation	64.44 µs/op	64.95 µs/op	0.8% more time	Not flagged
Capture and deliver events (4,096-byte payload, burst) Shard: capture	Lifetime peak process memory (RSS)	50.73 MiB	50.74 MiB	<0.1% more memory	Not flagged
Capture and deliver events (32-byte payload, steady) Shard: capture	Allocated memory per operation	117.68 KiB/op	117.68 KiB/op	<0.1% less memory	Not flagged
Capture and deliver events (32-byte payload, steady) Shard: capture	Allocations per operation	1,136.59 count/op	1,136.58 count/op	<0.1% fewer	Not flagged
Capture and deliver events (32-byte payload, steady) Shard: capture	Time per operation	58.94 µs/op	56.78 µs/op	3.7% less time	Not flagged
Capture and deliver events (32-byte payload, steady) Shard: capture	Idle process memory (RSS)	35.96 MiB	35.88 MiB	0.2% less memory	Not flagged
Capture and deliver events (32-byte payload, steady) Shard: capture	Observed peak process memory (RSS)	36.07 MiB	35.98 MiB	0.2% less memory	Not flagged
Capture and deliver events (32-byte payload, steady) Shard: capture	Process memory after settling (RSS)	36.07 MiB	35.98 MiB	0.2% less memory	Not flagged
Capture and deliver events (32-byte payload, steady) Shard: capture	Process CPU time per operation	59.28 µs/op	56.83 µs/op	4.1% less time	Not flagged
Capture and deliver events (32-byte payload, steady) Shard: capture	Lifetime peak process memory (RSS)	39.66 MiB	39.66 MiB	No observed change	Not flagged
Capture and deliver events (4,096-byte payload, steady) Shard: capture	Allocated memory per operation	170.57 KiB/op	170.57 KiB/op	<0.1% less memory	Not flagged
Capture and deliver events (4,096-byte payload, steady) Shard: capture	Allocations per operation	1,129.47 count/op	1,129.47 count/op	<0.1% more	Not flagged
Capture and deliver events (4,096-byte payload, steady) Shard: capture	Time per operation	68.8 µs/op	69.33 µs/op	0.8% more time	Not flagged
Capture and deliver events (4,096-byte payload, steady) Shard: capture	Idle process memory (RSS)	40.75 MiB	40.74 MiB	<0.1% less memory	Not flagged
Capture and deliver events (4,096-byte payload, steady) Shard: capture	Observed peak process memory (RSS)	40.75 MiB	40.75 MiB	<0.1% less memory	Not flagged
Capture and deliver events (4,096-byte payload, steady) Shard: capture	Process memory after settling (RSS)	40.75 MiB	40.75 MiB	<0.1% less memory	Not flagged
Capture and deliver events (4,096-byte payload, steady) Shard: capture	Process CPU time per operation	66.2 µs/op	66.71 µs/op	0.8% more time	Not flagged
Capture and deliver events (4,096-byte payload, steady) Shard: capture	Lifetime peak process memory (RSS)	40.94 MiB	41 MiB	0.2% more memory	Not flagged
Queue an event (32-byte payload) Shard: capture	Caller-thread CPU time per operation	33.19 µs/op	33.13 µs/op	0.2% less time	Not flagged
Queue an event (32-byte payload) Shard: capture	Time per operation	33.65 µs/op	33.73 µs/op	0.2% more time	Not flagged
Queue an event (4,096-byte payload) Shard: capture	Caller-thread CPU time per operation	33.32 µs/op	32.25 µs/op	3.2% less time	Not flagged
Queue an event (4,096-byte payload) Shard: capture	Time per operation	33.32 µs/op	32.24 µs/op	3.2% less time	Not flagged
Evaluate all 10 flags Shard: flags-scaling	Allocated memory per operation	200.98 KiB/op	200.98 KiB/op	No observed change	Not flagged
Evaluate all 10 flags Shard: flags-scaling	Allocations per operation	2,339.33 count/op	2,339.33 count/op	No observed change	Not flagged
Evaluate all 10 flags Shard: flags-scaling	Time per operation	113.58 µs/op	114.91 µs/op	1.2% more time	Not flagged
Evaluate all 10 flags Shard: flags-scaling	Process CPU time per operation	113.57 µs/op	114.91 µs/op	1.2% more time	Not flagged
Evaluate all 100 flags Shard: flags-scaling	Allocated memory per operation	1.93 MiB/op	1.93 MiB/op	No observed change	Not flagged
Evaluate all 100 flags Shard: flags-scaling	Allocations per operation	23,013.56 count/op	23,013.56 count/op	No observed change	Not flagged
Evaluate all 100 flags Shard: flags-scaling	Time per operation	1.12 ms/op	1.12 ms/op	0.6% less time	Not flagged
Evaluate all 100 flags Shard: flags-scaling	Process CPU time per operation	1.12 ms/op	1.12 ms/op	0.6% less time	Not flagged
Evaluate all 1,000 flags Shard: flags-scaling	Allocated memory per operation	19.24 MiB/op	19.24 MiB/op	No observed change	Not flagged
Evaluate all 1,000 flags Shard: flags-scaling	Allocations per operation	229,654.94 count/op	229,654.94 count/op	No observed change	Not flagged
Evaluate all 1,000 flags Shard: flags-scaling	Time per operation	12.24 ms/op	12.04 ms/op	1.7% less time	Not flagged
Evaluate all 1,000 flags Shard: flags-scaling	Process CPU time per operation	12.24 ms/op	12.03 ms/op	1.7% less time	Not flagged
Evaluate 1,000 flags under concurrent load Shard: flags-memory	Idle process memory (RSS)	41.64 MiB	42.32 MiB	1.6% more memory	Not flagged
Evaluate 1,000 flags under concurrent load Shard: flags-memory	Observed peak process memory (RSS)	41.98 MiB	42.65 MiB	1.6% more memory	Not flagged
Evaluate 1,000 flags under concurrent load Shard: flags-memory	Process memory after settling (RSS)	41.98 MiB	42.65 MiB	1.6% more memory	Not flagged
Evaluate 1,000 flags under concurrent load Shard: flags-memory	Lifetime peak process memory (RSS)	42.5 MiB	42.47 MiB	<0.1% less memory	Not flagged
Refresh 1,000 flag definitions Shard: flags-memory	Idle process memory (RSS)	42.09 MiB	41.9 MiB	0.5% less memory	Not flagged
Refresh 1,000 flag definitions Shard: flags-memory	Observed peak process memory (RSS)	42.14 MiB	42.5 MiB	0.8% more memory	Not flagged
Refresh 1,000 flag definitions Shard: flags-memory	Process memory after settling (RSS)	41.53 MiB	42.5 MiB	2.3% more memory	Not flagged
Refresh 1,000 flag definitions Shard: flags-memory	Lifetime peak process memory (RSS)	42.49 MiB	42.74 MiB	0.6% more memory	Not flagged
Evaluate one boolean flag Shard: flags-single	Allocated memory per operation	15.05 KiB/op	15.05 KiB/op	No observed change	Not flagged
Evaluate one boolean flag Shard: flags-single	Allocations per operation	173.76 count/op	173.76 count/op	No observed change	Not flagged
Evaluate one boolean flag Shard: flags-single	Time per operation	13.77 µs/op	13.64 µs/op	0.9% less time	Not flagged
Evaluate one boolean flag Shard: flags-single	Process CPU time per operation	13.77 µs/op	13.64 µs/op	0.9% less time	Not flagged
Evaluate a cohort-filtered flag Shard: flags-single	Allocated memory per operation	23.12 KiB/op	23.12 KiB/op	No observed change	Not flagged
Evaluate a cohort-filtered flag Shard: flags-single	Allocations per operation	270.27 count/op	270.27 count/op	No observed change	Not flagged
Evaluate a cohort-filtered flag Shard: flags-single	Time per operation	21.35 µs/op	21.41 µs/op	0.3% more time	Not flagged
Evaluate a cohort-filtered flag Shard: flags-single	Process CPU time per operation	21.35 µs/op	21.41 µs/op	0.3% more time	Not flagged
Evaluate a flag (early match) Shard: flags-single	Allocated memory per operation	35.71 KiB/op	35.71 KiB/op	No observed change	Not flagged
Evaluate a flag (early match) Shard: flags-single	Allocations per operation	387.27 count/op	387.27 count/op	No observed change	Not flagged
Evaluate a flag (early match) Shard: flags-single	Time per operation	27.29 µs/op	27.05 µs/op	0.9% less time	Not flagged
Evaluate a flag (early match) Shard: flags-single	Process CPU time per operation	27.29 µs/op	27.05 µs/op	0.9% less time	Not flagged
Evaluate a flag (late match) Shard: flags-single	Allocated memory per operation	53.59 KiB/op	53.59 KiB/op	No observed change	Not flagged
Evaluate a flag (late match) Shard: flags-single	Allocations per operation	576.27 count/op	576.27 count/op	No observed change	Not flagged
Evaluate a flag (late match) Shard: flags-single	Time per operation	37.74 µs/op	37.62 µs/op	0.3% less time	Not flagged
Evaluate a flag (late match) Shard: flags-single	Process CPU time per operation	37.74 µs/op	37.62 µs/op	0.3% less time	Not flagged
Evaluate a flag (no match) Shard: flags-single	Allocated memory per operation	52.14 KiB/op	52.14 KiB/op	No observed change	Not flagged
Evaluate a flag (no match) Shard: flags-single	Allocations per operation	556.77 count/op	556.77 count/op	No observed change	Not flagged
Evaluate a flag (no match) Shard: flags-single	Time per operation	34.13 µs/op	34.13 µs/op	<0.1% less time	Not flagged
Evaluate a flag (no match) Shard: flags-single	Process CPU time per operation	34.13 µs/op	34.12 µs/op	<0.1% less time	Not flagged
Evaluate a property-filtered flag Shard: flags-single	Allocated memory per operation	17.84 KiB/op	17.84 KiB/op	No observed change	Not flagged
Evaluate a property-filtered flag Shard: flags-single	Allocations per operation	198.27 count/op	198.27 count/op	No observed change	Not flagged
Evaluate a property-filtered flag Shard: flags-single	Time per operation	16.25 µs/op	16.33 µs/op	0.5% more time	Not flagged
Evaluate a property-filtered flag Shard: flags-single	Process CPU time per operation	16.25 µs/op	16.33 µs/op	0.5% more time	Not flagged
Evaluate a regex-filtered flag Shard: flags-single	Allocated memory per operation	19.23 KiB/op	19.23 KiB/op	No observed change	Not flagged
Evaluate a regex-filtered flag Shard: flags-single	Allocations per operation	210.77 count/op	210.77 count/op	No observed change	Not flagged
Evaluate a regex-filtered flag Shard: flags-single	Time per operation	17.25 µs/op	17.37 µs/op	0.7% more time	Not flagged
Evaluate a regex-filtered flag Shard: flags-single	Process CPU time per operation	17.25 µs/op	17.37 µs/op	0.7% more time	Not flagged
Evaluate a rollout flag Shard: flags-single	Allocated memory per operation	14.04 KiB/op	14.04 KiB/op	No observed change	Not flagged
Evaluate a rollout flag Shard: flags-single	Allocations per operation	160.76 count/op	160.76 count/op	No observed change	Not flagged
Evaluate a rollout flag Shard: flags-single	Time per operation	12.91 µs/op	12.83 µs/op	0.6% less time	Not flagged
Evaluate a rollout flag Shard: flags-single	Process CPU time per operation	12.91 µs/op	12.83 µs/op	0.6% less time	Not flagged
Evaluate a multivariate flag Shard: flags-single	Allocated memory per operation	15.21 KiB/op	15.21 KiB/op	No observed change	Not flagged
Evaluate a multivariate flag Shard: flags-single	Allocations per operation	177.77 count/op	177.77 count/op	No observed change	Not flagged
Evaluate a multivariate flag Shard: flags-single	Time per operation	14.3 µs/op	14.47 µs/op	1.2% more time	Not flagged
Evaluate a multivariate flag Shard: flags-single	Process CPU time per operation	14.3 µs/op	14.47 µs/op	1.2% more time	Not flagged

Values are medians of paired measurements. Not flagged does not mean unchanged. Unavailable means a measurement could not be provided, not zero. Estimated allocation measurements retain their instrumentation uncertainty. RSS measures the whole process, not just SDK allocations; observed peaks are sampled checkpoints. Paired ranges in the diagnostics describe variability, not confidence intervals.

Each shard uses its own runner; compare Before PR against With PR within a row, not across shards.

Compared 6b7c0ba3e72b8ebdc3b1f65aedafbb44c7c67256 → 3f98c16d18dec94fa16f57a2d717d54720da0e54.

Full report and diagnostics

102 metric rows; 102 rows shown in all results. Omitted or shortened data remain in comparison.json, including per-runner environments, resource limits, measurement methods, samples and checkpoints.