fix(profiling): workaround on-CPU Task race condition by KowalskiThomas · Pull Request #15780 · DataDog/dd-trace-py

KowalskiThomas · 2025-12-24T06:20:38Z

Description

Related PRs

Related: chore(profiling): detect cycles in asyncio #15712
Dependent: perf(profiling): unwind only one Frame per Task #15789
Research PR: https://github.com/DataDog/dd-trace-py/pull/15675/commits (if needed for code archeology...)

What is this about?

This PR updates the Task unwinding logic in the Profiler to (more) properly handle race conditions around running/"on CPU" Tasks. A Task can be either in a running state (i.e. actively computing something itself, like executing a regular Python function) or in a sleeping state (i.e. waiting for something else to happen to wake up).

After those changes, this problem does not appear anymore: only Frames that are actually from the same Stack appear within a given Stack.

Why do we need it?

Because we don't take a "snapshot of the whole Python process at once", there is a race condition in our Sampler.
We first capture the Thread Stack (i.e. for the current Thread, if it is running, what Python code the interpreter is running), then for each Task in the Thread's Event Loop [if it exists] we look at the Task's own Stack. (Since Task/Coroutines are pausable, they have their own Stack that is kept in memory when they're paused, then re-loaded into context when they're resumed. Walking each Task's Stack allows us to e.g. know what code they're "running", even when they aren't actually currently running code...)
Going back to the race condition question, we may have a discrepancy between what the Python Thread Stack tells us (what the interpreter is running) and what Task objects themselves tell us (because a tiny amount of time actually elapses between the moment we capture the Thread Stack and the moment we inspect the Task objects, so what is happening may have changed in the meantime).

I've already in the past gone into more detail regarding what buggy/unexpected behaviour may result from that race condition; this PR improves this.

Note that there is a pretty obvious tradeoff here. When we detect a discrepancy, we can:

Ignore the fact we know something bad is going to happen – I'd rather not do that because it can look terrible for customers (and we don't want to look obviously wrong to them). That would mean quantity over quality.
Try to recover by doing clever tricks (this can be somewhat costly because we have to interleave the various Stacks we have... I think we may want to do that at some point but not without putting more thought into it; plus those clever tricks can also sometimes be brittle tricks). That would mean quality and quantity over cost (which in practice probably also means quality over quantity because increasing costs will most probably lead to more adaptive sampling).
Give up and just pretend this never happened – skip that Sample (for the current Task, and in certain cases for the current Thread altogether). That would mean quality over quantity.

For the time being, things can only get better because we're in a state where we don't deal with the problem at all. The current PR biases towards a mix: we detect more reliably the depth of the pure Python Stack (which allows us not to rely on un-unwinding Task Stacks), and then we skip Samples that we know will be bogus. If the latter happens sufficiently rarely [a claim I still need numbers to back] then this is OK.

How does it work?

The main problem we are trying to avoid here is having some of Task A's Frames appearing as part of Task B's Stack. Working around this requires properly splitting the Python Stack when it says it is running a Task, such that we only push the asyncio runtime Frames on top of each non-Task A Task. Walking the Python Stack allows us to do that properly.

We thus walk the Python Stack (once per Thread) to detect whether we see Handle.run Frames – those indicate that the Event Loop is currently stepping the Coroutine – in other words executing code. (When that happens, we expect at least one Task to be marked as running (there could be more – that's also a race condition, but it's OK, as far as CPU Time is not concerned...))
As soon as we see a run Frame, we know the depth of the "pure Python Stack" and we can push it on top of every Task's Stack!

What does this cost us?

This is not completely free – we're doing more work (namely, walking the stack at each Sample). Looking at Full Host Profiles on a high-CPU asyncio-based Python script, I'm getting the following difference.
Note that the total Profiler overhead is about 360ms/minute, meaning the additional ~20ms we're using here represent an extra 5% overhead. Given the importance of getting Stacks right (or at least not completely wrong), I'd say it's worth it, but it's still noticeable.

I tried to do otherwise – but as far as I can tell, as long as the race condition between unwinding the Python Stack and unwinding Task Stacks exists (which it can't not), we will not be able to tell for sure how many pure Python Stack Frames we need to push. There are heuristics that can get us there in theoretically better time (e.g. only walk the Python Stack if all Tasks reported as non-running), but those come at a correctness and code readability cost, and it's not even that certain their overhead would be lesser.

I also have another PR that should reduce the cost of unwinding Tasks (that uses the fact we now walk the Python Stack only once): #15789 so hopefully it evens things out.

cit-pr-commenter · 2025-12-24T06:21:04Z

Codeowners resolved as

ddtrace/internal/datadog/profiling/stack/echion/echion/tasks.h          @DataDog/profiling-python
ddtrace/internal/datadog/profiling/stack/echion/echion/threads.h        @DataDog/profiling-python
releasenotes/notes/profiling-improve-on-cpu-stacks-f3047328da22fce1.yaml  @DataDog/apm-python
tests/profiling/collector/test_asyncio_recursive_on_cpu_tasks.py        @DataDog/profiling-python

pr-commenter · 2025-12-24T10:10:10Z

Performance SLOs

Comparing candidate kowalski/fix-profiling-workaround-for-on-cpu-task-race-condition-fix-reboot (7aa74f5) with baseline main (68228e0)

📈 Performance Regressions (3 suites)

📈 iastaspects - 118/118

✅ add_aspect

Time: ✅ 18.017µs (SLO: <20.000µs -9.9%) vs baseline: 📈 +21.4%

Memory: ✅ 42.566MB (SLO: <43.250MB 🟡 -1.6%) vs baseline: +5.0%

✅ add_inplace_aspect

Time: ✅ 14.880µs (SLO: <20.000µs 📉 -25.6%) vs baseline: -0.3%

Memory: ✅ 42.605MB (SLO: <43.250MB 🟡 -1.5%) vs baseline: +4.8%

✅ add_inplace_noaspect

Time: ✅ 0.338µs (SLO: <10.000µs 📉 -96.6%) vs baseline: +0.6%

Memory: ✅ 42.526MB (SLO: <43.500MB -2.2%) vs baseline: +4.7%

✅ add_noaspect

Time: ✅ 0.547µs (SLO: <10.000µs 📉 -94.5%) vs baseline: -0.5%

Memory: ✅ 42.546MB (SLO: <43.500MB -2.2%) vs baseline: +4.6%

✅ bytearray_aspect

Time: ✅ 17.899µs (SLO: <30.000µs 📉 -40.3%) vs baseline: -0.3%

Memory: ✅ 42.585MB (SLO: <43.500MB -2.1%) vs baseline: +4.7%

✅ bytearray_extend_aspect

Time: ✅ 23.966µs (SLO: <30.000µs 📉 -20.1%) vs baseline: +0.6%

Memory: ✅ 42.585MB (SLO: <43.500MB -2.1%) vs baseline: +5.0%

✅ bytearray_extend_noaspect

Time: ✅ 2.769µs (SLO: <10.000µs 📉 -72.3%) vs baseline: +0.6%

Memory: ✅ 42.625MB (SLO: <43.500MB -2.0%) vs baseline: +4.8%

✅ bytearray_noaspect

Time: ✅ 1.466µs (SLO: <10.000µs 📉 -85.3%) vs baseline: +0.2%

Memory: ✅ 42.605MB (SLO: <43.500MB -2.1%) vs baseline: +4.9%

✅ bytes_aspect

Time: ✅ 16.643µs (SLO: <20.000µs 📉 -16.8%) vs baseline: +0.5%

Memory: ✅ 42.566MB (SLO: <43.500MB -2.1%) vs baseline: +4.6%

✅ bytes_noaspect

Time: ✅ 1.414µs (SLO: <10.000µs 📉 -85.9%) vs baseline: -1.0%

Memory: ✅ 42.566MB (SLO: <43.500MB -2.1%) vs baseline: +4.9%

✅ bytesio_aspect

Time: ✅ 55.593µs (SLO: <70.000µs 📉 -20.6%) vs baseline: ~same

Memory: ✅ 42.585MB (SLO: <43.500MB -2.1%) vs baseline: +4.7%

✅ bytesio_noaspect

Time: ✅ 3.277µs (SLO: <10.000µs 📉 -67.2%) vs baseline: +0.8%

Memory: ✅ 42.605MB (SLO: <43.500MB -2.1%) vs baseline: +4.8%

✅ capitalize_aspect

Time: ✅ 14.691µs (SLO: <20.000µs 📉 -26.5%) vs baseline: +0.2%

Memory: ✅ 42.625MB (SLO: <43.500MB -2.0%) vs baseline: +4.9%

✅ capitalize_noaspect

Time: ✅ 2.572µs (SLO: <10.000µs 📉 -74.3%) vs baseline: -1.2%

Memory: ✅ 42.585MB (SLO: <43.500MB -2.1%) vs baseline: +4.8%

✅ casefold_aspect

Time: ✅ 14.595µs (SLO: <20.000µs 📉 -27.0%) vs baseline: -0.2%

Memory: ✅ 42.566MB (SLO: <43.500MB -2.1%) vs baseline: +5.0%

✅ casefold_noaspect

Time: ✅ 3.161µs (SLO: <10.000µs 📉 -68.4%) vs baseline: ~same

Memory: ✅ 42.585MB (SLO: <43.500MB -2.1%) vs baseline: +4.7%

✅ decode_aspect

Time: ✅ 15.508µs (SLO: <30.000µs 📉 -48.3%) vs baseline: -0.4%

Memory: ✅ 42.703MB (SLO: <43.500MB 🟡 -1.8%) vs baseline: +4.9%

✅ decode_noaspect

Time: ✅ 1.603µs (SLO: <10.000µs 📉 -84.0%) vs baseline: -0.6%

Memory: ✅ 42.546MB (SLO: <43.500MB -2.2%) vs baseline: +4.8%

✅ encode_aspect

Time: ✅ 18.208µs (SLO: <30.000µs 📉 -39.3%) vs baseline: 📈 +23.1%

Memory: ✅ 42.566MB (SLO: <43.500MB -2.1%) vs baseline: +4.8%

✅ encode_noaspect

Time: ✅ 1.508µs (SLO: <10.000µs 📉 -84.9%) vs baseline: +0.5%

Memory: ✅ 42.644MB (SLO: <43.500MB 🟡 -2.0%) vs baseline: +4.9%

✅ format_aspect

Time: ✅ 170.911µs (SLO: <200.000µs 📉 -14.5%) vs baseline: ~same

Memory: ✅ 42.723MB (SLO: <43.250MB 🟡 -1.2%) vs baseline: +4.9%

✅ format_map_aspect

Time: ✅ 190.851µs (SLO: <200.000µs -4.6%) vs baseline: +0.1%

Memory: ✅ 42.723MB (SLO: <43.500MB 🟡 -1.8%) vs baseline: +4.8%

✅ format_map_noaspect

Time: ✅ 3.835µs (SLO: <10.000µs 📉 -61.7%) vs baseline: +0.4%

Memory: ✅ 42.605MB (SLO: <43.250MB 🟡 -1.5%) vs baseline: +4.8%

✅ format_noaspect

Time: ✅ 3.143µs (SLO: <10.000µs 📉 -68.6%) vs baseline: -0.5%

Memory: ✅ 42.664MB (SLO: <43.250MB 🟡 -1.4%) vs baseline: +5.1%

✅ index_aspect

Time: ✅ 15.453µs (SLO: <20.000µs 📉 -22.7%) vs baseline: +0.9%

Memory: ✅ 42.546MB (SLO: <43.250MB 🟡 -1.6%) vs baseline: +4.6%

✅ index_noaspect

Time: ✅ 0.462µs (SLO: <10.000µs 📉 -95.4%) vs baseline: ~same

Memory: ✅ 42.566MB (SLO: <43.500MB -2.1%) vs baseline: +4.6%

✅ join_aspect

Time: ✅ 17.020µs (SLO: <20.000µs 📉 -14.9%) vs baseline: -0.5%

Memory: ✅ 42.703MB (SLO: <43.500MB 🟡 -1.8%) vs baseline: +5.2%

✅ join_noaspect

Time: ✅ 1.566µs (SLO: <10.000µs 📉 -84.3%) vs baseline: +0.7%

Memory: ✅ 42.566MB (SLO: <43.250MB 🟡 -1.6%) vs baseline: +4.8%

✅ ljust_aspect

Time: ✅ 20.785µs (SLO: <30.000µs 📉 -30.7%) vs baseline: +0.2%

Memory: ✅ 42.644MB (SLO: <43.250MB 🟡 -1.4%) vs baseline: +5.1%

✅ ljust_noaspect

Time: ✅ 2.719µs (SLO: <10.000µs 📉 -72.8%) vs baseline: +0.2%

Memory: ✅ 42.625MB (SLO: <43.250MB 🟡 -1.4%) vs baseline: +4.9%

✅ lower_aspect

Time: ✅ 17.902µs (SLO: <30.000µs 📉 -40.3%) vs baseline: +0.4%

Memory: ✅ 42.526MB (SLO: <43.500MB -2.2%) vs baseline: +4.8%

✅ lower_noaspect

Time: ✅ 2.423µs (SLO: <10.000µs 📉 -75.8%) vs baseline: +0.3%

Memory: ✅ 42.605MB (SLO: <43.250MB 🟡 -1.5%) vs baseline: +4.7%

✅ lstrip_aspect

Time: ✅ 17.679µs (SLO: <30.000µs 📉 -41.1%) vs baseline: -0.1%

Memory: ✅ 42.605MB (SLO: <43.250MB 🟡 -1.5%) vs baseline: +4.7%

✅ lstrip_noaspect

Time: ✅ 1.868µs (SLO: <10.000µs 📉 -81.3%) vs baseline: +1.5%

Memory: ✅ 42.526MB (SLO: <43.500MB -2.2%) vs baseline: +4.8%

✅ modulo_aspect

Time: ✅ 166.326µs (SLO: <200.000µs 📉 -16.8%) vs baseline: -0.3%

Memory: ✅ 42.664MB (SLO: <43.500MB 🟡 -1.9%) vs baseline: +5.0%

✅ modulo_aspect_for_bytearray_bytearray

Time: ✅ 174.105µs (SLO: <200.000µs 📉 -12.9%) vs baseline: -0.2%

Memory: ✅ 42.841MB (SLO: <43.500MB 🟡 -1.5%) vs baseline: +5.4%

✅ modulo_aspect_for_bytes

Time: ✅ 168.676µs (SLO: <200.000µs 📉 -15.7%) vs baseline: ~same

Memory: ✅ 42.723MB (SLO: <43.500MB 🟡 -1.8%) vs baseline: +4.5%

✅ modulo_aspect_for_bytes_bytearray

Time: ✅ 171.649µs (SLO: <200.000µs 📉 -14.2%) vs baseline: -0.3%

Memory: ✅ 42.644MB (SLO: <43.500MB 🟡 -2.0%) vs baseline: +4.5%

✅ modulo_noaspect

Time: ✅ 3.756µs (SLO: <10.000µs 📉 -62.4%) vs baseline: +2.3%

Memory: ✅ 42.664MB (SLO: <43.500MB 🟡 -1.9%) vs baseline: +5.1%

✅ replace_aspect

Time: ✅ 212.037µs (SLO: <300.000µs 📉 -29.3%) vs baseline: +0.1%

Memory: ✅ 42.723MB (SLO: <44.000MB -2.9%) vs baseline: +4.5%

✅ replace_noaspect

Time: ✅ 2.924µs (SLO: <10.000µs 📉 -70.8%) vs baseline: +0.6%

Memory: ✅ 42.566MB (SLO: <43.500MB -2.1%) vs baseline: +4.7%

✅ repr_aspect

Time: ✅ 1.418µs (SLO: <10.000µs 📉 -85.8%) vs baseline: ~same

Memory: ✅ 42.566MB (SLO: <43.500MB -2.1%) vs baseline: +4.8%

✅ repr_noaspect

Time: ✅ 0.523µs (SLO: <10.000µs 📉 -94.8%) vs baseline: +0.2%

Memory: ✅ 42.526MB (SLO: <43.500MB -2.2%) vs baseline: +4.4%

✅ rstrip_aspect

Time: ✅ 19.058µs (SLO: <30.000µs 📉 -36.5%) vs baseline: +0.5%

Memory: ✅ 42.723MB (SLO: <43.500MB 🟡 -1.8%) vs baseline: +5.1%

✅ rstrip_noaspect

Time: ✅ 2.049µs (SLO: <10.000µs 📉 -79.5%) vs baseline: +6.5%

Memory: ✅ 42.566MB (SLO: <43.500MB -2.1%) vs baseline: +4.8%

✅ slice_aspect

Time: ✅ 15.900µs (SLO: <20.000µs 📉 -20.5%) vs baseline: +0.4%

Memory: ✅ 42.507MB (SLO: <43.500MB -2.3%) vs baseline: +4.7%

✅ slice_noaspect

Time: ✅ 0.598µs (SLO: <10.000µs 📉 -94.0%) vs baseline: +0.3%

Memory: ✅ 42.625MB (SLO: <43.500MB -2.0%) vs baseline: +5.1%

✅ stringio_aspect

Time: ✅ 54.131µs (SLO: <80.000µs 📉 -32.3%) vs baseline: +0.5%

Memory: ✅ 42.625MB (SLO: <43.500MB -2.0%) vs baseline: +5.1%

✅ stringio_noaspect

Time: ✅ 3.631µs (SLO: <10.000µs 📉 -63.7%) vs baseline: -0.9%

Memory: ✅ 42.585MB (SLO: <43.500MB -2.1%) vs baseline: +4.9%

✅ strip_aspect

Time: ✅ 17.655µs (SLO: <20.000µs 📉 -11.7%) vs baseline: +0.4%

Memory: ✅ 42.546MB (SLO: <43.500MB -2.2%) vs baseline: +4.8%

✅ strip_noaspect

Time: ✅ 1.876µs (SLO: <10.000µs 📉 -81.2%) vs baseline: +0.8%

Memory: ✅ 42.585MB (SLO: <43.500MB -2.1%) vs baseline: +4.8%

✅ swapcase_aspect

Time: ✅ 18.448µs (SLO: <30.000µs 📉 -38.5%) vs baseline: -0.3%

Memory: ✅ 42.625MB (SLO: <43.500MB -2.0%) vs baseline: +4.9%

✅ swapcase_noaspect

Time: ✅ 2.789µs (SLO: <10.000µs 📉 -72.1%) vs baseline: +0.5%

Memory: ✅ 42.526MB (SLO: <43.500MB -2.2%) vs baseline: +4.8%

✅ title_aspect

Time: ✅ 21.977µs (SLO: <30.000µs 📉 -26.7%) vs baseline: 📈 +21.1%

Memory: ✅ 42.605MB (SLO: <43.000MB 🟡 -0.9%) vs baseline: +4.9%

✅ title_noaspect

Time: ✅ 2.665µs (SLO: <10.000µs 📉 -73.3%) vs baseline: ~same

Memory: ✅ 42.664MB (SLO: <43.500MB 🟡 -1.9%) vs baseline: +5.1%

✅ translate_aspect

Time: ✅ 20.471µs (SLO: <30.000µs 📉 -31.8%) vs baseline: -0.5%

Memory: ✅ 42.566MB (SLO: <43.500MB -2.1%) vs baseline: +4.8%

✅ translate_noaspect

Time: ✅ 4.320µs (SLO: <10.000µs 📉 -56.8%) vs baseline: -0.5%

Memory: ✅ 42.546MB (SLO: <43.500MB -2.2%) vs baseline: +4.5%

✅ upper_aspect

Time: ✅ 17.971µs (SLO: <30.000µs 📉 -40.1%) vs baseline: -0.2%

Memory: ✅ 42.605MB (SLO: <43.500MB -2.1%) vs baseline: +5.1%

✅ upper_noaspect

Time: ✅ 2.430µs (SLO: <10.000µs 📉 -75.7%) vs baseline: -1.0%

Memory: ✅ 42.585MB (SLO: <43.500MB -2.1%) vs baseline: +5.0%

📈 iastaspectsospath - 24/24

✅ ospathbasename_aspect

Time: ✅ 5.159µs (SLO: <10.000µs 📉 -48.4%) vs baseline: 📈 +21.8%

Memory: ✅ 42.507MB (SLO: <43.500MB -2.3%) vs baseline: +4.9%

✅ ospathbasename_noaspect

Time: ✅ 4.290µs (SLO: <10.000µs 📉 -57.1%) vs baseline: ~same

Memory: ✅ 42.546MB (SLO: <43.500MB -2.2%) vs baseline: +4.7%

✅ ospathjoin_aspect

Time: ✅ 6.249µs (SLO: <10.000µs 📉 -37.5%) vs baseline: ~same

Memory: ✅ 42.507MB (SLO: <43.500MB -2.3%) vs baseline: +4.7%

✅ ospathjoin_noaspect

Time: ✅ 6.294µs (SLO: <10.000µs 📉 -37.1%) vs baseline: -0.1%

Memory: ✅ 42.566MB (SLO: <43.500MB -2.1%) vs baseline: +4.7%

✅ ospathnormcase_aspect

Time: ✅ 3.585µs (SLO: <10.000µs 📉 -64.1%) vs baseline: +0.2%

Memory: ✅ 42.605MB (SLO: <43.500MB -2.1%) vs baseline: +4.9%

✅ ospathnormcase_noaspect

Time: ✅ 3.620µs (SLO: <10.000µs 📉 -63.8%) vs baseline: ~same

Memory: ✅ 42.625MB (SLO: <43.500MB -2.0%) vs baseline: +5.0%

✅ ospathsplit_aspect

Time: ✅ 4.870µs (SLO: <10.000µs 📉 -51.3%) vs baseline: -0.8%

Memory: ✅ 42.546MB (SLO: <43.500MB -2.2%) vs baseline: +5.0%

✅ ospathsplit_noaspect

Time: ✅ 5.036µs (SLO: <10.000µs 📉 -49.6%) vs baseline: +0.7%

Memory: ✅ 42.546MB (SLO: <43.500MB -2.2%) vs baseline: +4.8%

✅ ospathsplitdrive_aspect

Time: ✅ 3.759µs (SLO: <10.000µs 📉 -62.4%) vs baseline: -0.6%

Memory: ✅ 42.585MB (SLO: <43.500MB -2.1%) vs baseline: +4.9%

✅ ospathsplitdrive_noaspect

Time: ✅ 0.744µs (SLO: <10.000µs 📉 -92.6%) vs baseline: -0.9%

Memory: ✅ 42.625MB (SLO: <43.500MB -2.0%) vs baseline: +4.9%

✅ ospathsplitext_aspect

Time: ✅ 4.632µs (SLO: <10.000µs 📉 -53.7%) vs baseline: -0.5%

Memory: ✅ 42.605MB (SLO: <43.500MB -2.1%) vs baseline: +5.0%

✅ ospathsplitext_noaspect

Time: ✅ 4.625µs (SLO: <10.000µs 📉 -53.8%) vs baseline: -1.0%

Memory: ✅ 42.566MB (SLO: <43.500MB -2.1%) vs baseline: +4.9%

📈 telemetryaddmetric - 30/30

✅ 1-count-metric-1-times

Time: ✅ 3.350µs (SLO: <20.000µs 📉 -83.2%) vs baseline: 📈 +11.3%

Memory: ✅ 34.859MB (SLO: <35.500MB 🟡 -1.8%) vs baseline: +4.6%

✅ 1-count-metrics-100-times

Time: ✅ 197.977µs (SLO: <220.000µs 📉 -10.0%) vs baseline: -0.8%

Memory: ✅ 34.878MB (SLO: <35.500MB 🟡 -1.8%) vs baseline: +4.4%

✅ 1-distribution-metric-1-times

Time: ✅ 3.320µs (SLO: <20.000µs 📉 -83.4%) vs baseline: +0.1%

Memory: ✅ 34.819MB (SLO: <35.500MB 🟡 -1.9%) vs baseline: +4.5%

✅ 1-distribution-metrics-100-times

Time: ✅ 211.905µs (SLO: <230.000µs -7.9%) vs baseline: -1.4%

Memory: ✅ 34.800MB (SLO: <35.500MB 🟡 -2.0%) vs baseline: +4.7%

✅ 1-gauge-metric-1-times

Time: ✅ 2.194µs (SLO: <20.000µs 📉 -89.0%) vs baseline: -0.8%

Memory: ✅ 34.780MB (SLO: <35.500MB -2.0%) vs baseline: +4.5%

✅ 1-gauge-metrics-100-times

Time: ✅ 136.231µs (SLO: <150.000µs -9.2%) vs baseline: -0.6%

Memory: ✅ 34.898MB (SLO: <35.500MB 🟡 -1.7%) vs baseline: +4.9%

✅ 1-rate-metric-1-times

Time: ✅ 3.102µs (SLO: <20.000µs 📉 -84.5%) vs baseline: -0.7%

Memory: ✅ 34.859MB (SLO: <35.500MB 🟡 -1.8%) vs baseline: +5.2%

✅ 1-rate-metrics-100-times

Time: ✅ 212.319µs (SLO: <250.000µs 📉 -15.1%) vs baseline: +0.8%

Memory: ✅ 34.937MB (SLO: <35.500MB 🟡 -1.6%) vs baseline: +5.0%

✅ 100-count-metrics-100-times

Time: ✅ 19.935ms (SLO: <22.000ms -9.4%) vs baseline: +0.3%

Memory: ✅ 34.780MB (SLO: <35.500MB -2.0%) vs baseline: +4.7%

✅ 100-distribution-metrics-100-times

Time: ✅ 2.207ms (SLO: <2.550ms 📉 -13.4%) vs baseline: -1.6%

Memory: ✅ 34.859MB (SLO: <35.500MB 🟡 -1.8%) vs baseline: +5.0%

✅ 100-gauge-metrics-100-times

Time: ✅ 1.412ms (SLO: <1.550ms -8.9%) vs baseline: +1.3%

Memory: ✅ 34.878MB (SLO: <35.500MB 🟡 -1.8%) vs baseline: +4.9%

✅ 100-rate-metrics-100-times

Time: ✅ 2.183ms (SLO: <2.550ms 📉 -14.4%) vs baseline: ~same

Memory: ✅ 34.780MB (SLO: <35.500MB -2.0%) vs baseline: +4.9%

✅ flush-1-metric

Time: ✅ 4.529µs (SLO: <20.000µs 📉 -77.4%) vs baseline: -1.0%

Memory: ✅ 34.800MB (SLO: <35.500MB 🟡 -2.0%) vs baseline: +4.7%

✅ flush-100-metrics

Time: ✅ 173.730µs (SLO: <250.000µs 📉 -30.5%) vs baseline: ~same

Memory: ✅ 35.154MB (SLO: <35.500MB 🟡 -1.0%) vs baseline: +4.9%

✅ flush-1000-metrics

Time: ✅ 2.177ms (SLO: <2.500ms 📉 -12.9%) vs baseline: +0.1%

Memory: ✅ 35.979MB (SLO: <36.500MB 🟡 -1.4%) vs baseline: +4.5%

🟡 Near SLO Breach (16 suites)

🟡 coreapiscenario - 10/10 (1 unstable)

⚠️ context_with_data_listeners

Time: ⚠️ 13.290µs (SLO: <20.000µs 📉 -33.6%) vs baseline: +0.4%

Memory: ✅ 34.898MB (SLO: <35.500MB 🟡 -1.7%) vs baseline: +4.6%

✅ context_with_data_no_listeners

Time: ✅ 3.277µs (SLO: <10.000µs 📉 -67.2%) vs baseline: +0.5%

Memory: ✅ 34.859MB (SLO: <35.500MB 🟡 -1.8%) vs baseline: +4.7%

✅ get_item_exists

Time: ✅ 0.575µs (SLO: <10.000µs 📉 -94.2%) vs baseline: -1.0%

Memory: ✅ 34.839MB (SLO: <35.500MB 🟡 -1.9%) vs baseline: +4.5%

✅ get_item_missing

Time: ✅ 0.634µs (SLO: <10.000µs 📉 -93.7%) vs baseline: -0.7%

Memory: ✅ 34.878MB (SLO: <35.500MB 🟡 -1.8%) vs baseline: +4.9%

✅ set_item

Time: ✅ 24.232µs (SLO: <30.000µs 📉 -19.2%) vs baseline: +0.7%

Memory: ✅ 34.898MB (SLO: <35.500MB 🟡 -1.7%) vs baseline: +5.0%

🟡 djangosimple - 30/30

✅ appsec

Time: ✅ 19.616ms (SLO: <22.300ms 📉 -12.0%) vs baseline: ~same

Memory: ✅ 68.361MB (SLO: <70.500MB -3.0%) vs baseline: +4.8%

✅ exception-replay-enabled

Time: ✅ 1.360ms (SLO: <1.450ms -6.2%) vs baseline: -0.4%

Memory: ✅ 66.344MB (SLO: <67.500MB 🟡 -1.7%) vs baseline: +4.8%

✅ iast

Time: ✅ 19.596ms (SLO: <22.250ms 📉 -11.9%) vs baseline: ~same

Memory: ✅ 68.400MB (SLO: <70.000MB -2.3%) vs baseline: +5.1%

✅ profiler

Time: ✅ 14.779ms (SLO: <16.550ms 📉 -10.7%) vs baseline: +0.1%

Memory: ✅ 56.380MB (SLO: <57.500MB 🟡 -1.9%) vs baseline: +4.9%

✅ resource-renaming

Time: ✅ 19.396ms (SLO: <21.750ms 📉 -10.8%) vs baseline: -1.0%

Memory: ✅ 68.420MB (SLO: <70.500MB -3.0%) vs baseline: +4.9%

✅ span-code-origin

Time: ✅ 19.925ms (SLO: <28.200ms 📉 -29.3%) vs baseline: +0.7%

Memory: ✅ 68.215MB (SLO: <71.000MB -3.9%) vs baseline: +4.8%

✅ tracer

Time: ✅ 19.615ms (SLO: <21.750ms -9.8%) vs baseline: ~same

Memory: ✅ 68.321MB (SLO: <70.000MB -2.4%) vs baseline: +4.8%

✅ tracer-and-profiler

Time: ✅ 20.870ms (SLO: <23.500ms 📉 -11.2%) vs baseline: ~same

Memory: ✅ 69.363MB (SLO: <71.000MB -2.3%) vs baseline: +4.9%

✅ tracer-dont-create-db-spans

Time: ✅ 19.621ms (SLO: <21.500ms -8.7%) vs baseline: ~same

Memory: ✅ 68.479MB (SLO: <70.000MB -2.2%) vs baseline: +5.0%

✅ tracer-minimal

Time: ✅ 16.727ms (SLO: <17.500ms -4.4%) vs baseline: -0.5%

Memory: ✅ 68.243MB (SLO: <70.000MB -2.5%) vs baseline: +4.9%

✅ tracer-native

Time: ✅ 19.515ms (SLO: <21.750ms 📉 -10.3%) vs baseline: +0.3%

Memory: ✅ 68.341MB (SLO: <72.500MB -5.7%) vs baseline: +4.8%

✅ tracer-no-caches

Time: ✅ 17.988ms (SLO: <19.650ms -8.5%) vs baseline: +2.1%

Memory: ✅ 68.302MB (SLO: <70.000MB -2.4%) vs baseline: +4.7%

✅ tracer-no-databases

Time: ✅ 19.513ms (SLO: <20.100ms -2.9%) vs baseline: +1.9%

Memory: ✅ 68.164MB (SLO: <70.000MB -2.6%) vs baseline: +5.1%

✅ tracer-no-middleware

Time: ✅ 19.314ms (SLO: <21.500ms 📉 -10.2%) vs baseline: -0.3%

Memory: ✅ 68.361MB (SLO: <70.000MB -2.3%) vs baseline: +5.0%

✅ tracer-no-templates

Time: ✅ 19.393ms (SLO: <22.000ms 📉 -11.8%) vs baseline: +0.9%

Memory: ✅ 68.361MB (SLO: <70.500MB -3.0%) vs baseline: +4.9%

🟡 errortrackingdjangosimple - 6/6

✅ errortracking-enabled-all

Time: ✅ 16.329ms (SLO: <19.850ms 📉 -17.7%) vs baseline: -0.1%

Memory: ✅ 69.840MB (SLO: <70.000MB 🟡 -0.2%) vs baseline: +4.9%

✅ errortracking-enabled-user

Time: ✅ 16.364ms (SLO: <19.400ms 📉 -15.6%) vs baseline: +0.5%

Memory: ✅ 69.860MB (SLO: <70.000MB 🟡 -0.2%) vs baseline: +4.9%

✅ tracer-enabled

Time: ✅ 16.290ms (SLO: <19.450ms 📉 -16.2%) vs baseline: -0.2%

Memory: ✅ 69.918MB (SLO: <70.000MB 🟡 -0.1%) vs baseline: +4.8%

🟡 errortrackingflasksqli - 6/6

✅ errortracking-enabled-all

Time: ✅ 2.066ms (SLO: <2.300ms 📉 -10.2%) vs baseline: ~same

Memory: ✅ 55.896MB (SLO: <56.500MB 🟡 -1.1%) vs baseline: +4.9%

✅ errortracking-enabled-user

Time: ✅ 2.074ms (SLO: <2.250ms -7.8%) vs baseline: ~same

Memory: ✅ 55.915MB (SLO: <56.500MB 🟡 -1.0%) vs baseline: +4.9%

✅ tracer-enabled

Time: ✅ 2.066ms (SLO: <2.300ms 📉 -10.2%) vs baseline: ~same

Memory: ✅ 55.915MB (SLO: <56.500MB 🟡 -1.0%) vs baseline: +4.7%

🟡 flasksimple - 18/18

✅ appsec-get

Time: ✅ 3.395ms (SLO: <4.750ms 📉 -28.5%) vs baseline: +0.5%

Memory: ✅ 55.951MB (SLO: <66.500MB 📉 -15.9%) vs baseline: +5.0%

✅ appsec-post

Time: ✅ 2.852ms (SLO: <6.750ms 📉 -57.7%) vs baseline: ~same

Memory: ✅ 55.857MB (SLO: <66.500MB 📉 -16.0%) vs baseline: +4.7%

✅ appsec-telemetry

Time: ✅ 3.400ms (SLO: <4.750ms 📉 -28.4%) vs baseline: +1.2%

Memory: ✅ 55.918MB (SLO: <66.500MB 📉 -15.9%) vs baseline: +4.9%

✅ debugger

Time: ✅ 1.868ms (SLO: <2.000ms -6.6%) vs baseline: -0.1%

Memory: ✅ 47.781MB (SLO: <49.500MB -3.5%) vs baseline: +5.1%

✅ iast-get

Time: ✅ 1.859ms (SLO: <2.000ms -7.0%) vs baseline: ~same

Memory: ✅ 44.859MB (SLO: <49.000MB -8.5%) vs baseline: +5.0%

✅ profiler

Time: ✅ 1.858ms (SLO: <2.100ms 📉 -11.5%) vs baseline: ~same

Memory: ✅ 48.709MB (SLO: <50.000MB -2.6%) vs baseline: +5.0%

✅ resource-renaming

Time: ✅ 3.354ms (SLO: <3.650ms -8.1%) vs baseline: +0.1%

Memory: ✅ 55.839MB (SLO: <56.000MB 🟡 -0.3%) vs baseline: +4.8%

✅ tracer

Time: ✅ 3.372ms (SLO: <3.650ms -7.6%) vs baseline: +0.2%

Memory: ✅ 55.802MB (SLO: <56.500MB 🟡 -1.2%) vs baseline: +4.9%

✅ tracer-native

Time: ✅ 3.366ms (SLO: <3.650ms -7.8%) vs baseline: ~same

Memory: ✅ 55.888MB (SLO: <60.000MB -6.9%) vs baseline: +4.9%

🟡 flasksqli - 6/6

✅ appsec-enabled

Time: ✅ 2.063ms (SLO: <4.200ms 📉 -50.9%) vs baseline: +0.2%

Memory: ✅ 55.915MB (SLO: <66.000MB 📉 -15.3%) vs baseline: +4.8%

✅ iast-enabled

Time: ✅ 2.065ms (SLO: <2.800ms 📉 -26.2%) vs baseline: -0.2%

Memory: ✅ 55.935MB (SLO: <62.500MB 📉 -10.5%) vs baseline: +5.1%

✅ tracer-enabled

Time: ✅ 2.061ms (SLO: <2.250ms -8.4%) vs baseline: +0.2%

Memory: ✅ 55.896MB (SLO: <56.500MB 🟡 -1.1%) vs baseline: +4.9%

🟡 httppropagationextract - 60/60

✅ all_styles_all_headers

Time: ✅ 81.089µs (SLO: <100.000µs 📉 -18.9%) vs baseline: -1.0%

Memory: ✅ 34.937MB (SLO: <35.500MB 🟡 -1.6%) vs baseline: +4.9%

✅ b3_headers

Time: ✅ 14.310µs (SLO: <20.000µs 📉 -28.4%) vs baseline: -0.7%

Memory: ✅ 34.898MB (SLO: <35.500MB 🟡 -1.7%) vs baseline: +4.7%

✅ b3_single_headers

Time: ✅ 13.467µs (SLO: <20.000µs 📉 -32.7%) vs baseline: ~same

Memory: ✅ 34.937MB (SLO: <35.500MB 🟡 -1.6%) vs baseline: +4.8%

✅ datadog_tracecontext_tracestate_not_propagated_on_trace_id_no_match

Time: ✅ 64.173µs (SLO: <80.000µs 📉 -19.8%) vs baseline: ~same

Memory: ✅ 34.977MB (SLO: <35.500MB 🟡 -1.5%) vs baseline: +4.8%

✅ datadog_tracecontext_tracestate_propagated_on_trace_id_match

Time: ✅ 66.154µs (SLO: <80.000µs 📉 -17.3%) vs baseline: -0.3%

Memory: ✅ 34.937MB (SLO: <35.500MB 🟡 -1.6%) vs baseline: +4.8%

✅ empty_headers

Time: ✅ 1.627µs (SLO: <10.000µs 📉 -83.7%) vs baseline: +2.3%

Memory: ✅ 34.918MB (SLO: <35.500MB 🟡 -1.6%) vs baseline: +4.7%

✅ full_t_id_datadog_headers

Time: ✅ 22.703µs (SLO: <30.000µs 📉 -24.3%) vs baseline: -0.4%

Memory: ✅ 34.859MB (SLO: <35.500MB 🟡 -1.8%) vs baseline: +4.7%

✅ invalid_priority_header

Time: ✅ 6.496µs (SLO: <10.000µs 📉 -35.0%) vs baseline: ~same

Memory: ✅ 34.977MB (SLO: <35.500MB 🟡 -1.5%) vs baseline: +4.7%

✅ invalid_span_id_header

Time: ✅ 6.500µs (SLO: <10.000µs 📉 -35.0%) vs baseline: -0.1%

Memory: ✅ 34.996MB (SLO: <35.500MB 🟡 -1.4%) vs baseline: +4.9%

✅ invalid_tags_header

Time: ✅ 6.495µs (SLO: <10.000µs 📉 -35.0%) vs baseline: +0.4%

Memory: ✅ 34.918MB (SLO: <35.500MB 🟡 -1.6%) vs baseline: +4.6%

✅ invalid_trace_id_header

Time: ✅ 6.596µs (SLO: <10.000µs 📉 -34.0%) vs baseline: +0.9%

Memory: ✅ 34.996MB (SLO: <35.500MB 🟡 -1.4%) vs baseline: +5.0%

✅ large_header_no_matches

Time: ✅ 27.725µs (SLO: <30.000µs -7.6%) vs baseline: +0.3%

Memory: ✅ 34.918MB (SLO: <35.500MB 🟡 -1.6%) vs baseline: +4.7%

✅ large_valid_headers_all

Time: ✅ 28.632µs (SLO: <40.000µs 📉 -28.4%) vs baseline: +0.5%

Memory: ✅ 34.957MB (SLO: <35.500MB 🟡 -1.5%) vs baseline: +4.9%

✅ medium_header_no_matches

Time: ✅ 9.812µs (SLO: <20.000µs 📉 -50.9%) vs baseline: -0.2%

Memory: ✅ 34.977MB (SLO: <35.500MB 🟡 -1.5%) vs baseline: +5.0%

✅ medium_valid_headers_all

Time: ✅ 11.339µs (SLO: <20.000µs 📉 -43.3%) vs baseline: +1.0%

Memory: ✅ 34.878MB (SLO: <35.500MB 🟡 -1.8%) vs baseline: +4.6%

✅ none_propagation_style

Time: ✅ 1.710µs (SLO: <10.000µs 📉 -82.9%) vs baseline: +1.0%

Memory: ✅ 34.918MB (SLO: <35.500MB 🟡 -1.6%) vs baseline: +4.6%

✅ tracecontext_headers

Time: ✅ 34.743µs (SLO: <40.000µs 📉 -13.1%) vs baseline: -1.2%

Memory: ✅ 34.898MB (SLO: <35.500MB 🟡 -1.7%) vs baseline: +4.6%

✅ valid_headers_all

Time: ✅ 6.484µs (SLO: <10.000µs 📉 -35.2%) vs baseline: -0.1%

Memory: ✅ 34.937MB (SLO: <35.500MB 🟡 -1.6%) vs baseline: +4.9%

✅ valid_headers_basic

Time: ✅ 6.083µs (SLO: <10.000µs 📉 -39.2%) vs baseline: ~same

Memory: ✅ 35.016MB (SLO: <35.500MB 🟡 -1.4%) vs baseline: +5.0%

✅ wsgi_empty_headers

Time: ✅ 1.598µs (SLO: <10.000µs 📉 -84.0%) vs baseline: +0.3%

Memory: ✅ 34.977MB (SLO: <35.500MB 🟡 -1.5%) vs baseline: +4.8%

✅ wsgi_invalid_priority_header

Time: ✅ 6.504µs (SLO: <10.000µs 📉 -35.0%) vs baseline: -0.2%

Memory: ✅ 34.898MB (SLO: <35.500MB 🟡 -1.7%) vs baseline: +4.2%

✅ wsgi_invalid_span_id_header

Time: ✅ 1.596µs (SLO: <10.000µs 📉 -84.0%) vs baseline: +0.7%

Memory: ✅ 34.918MB (SLO: <35.500MB 🟡 -1.6%) vs baseline: +4.6%

✅ wsgi_invalid_tags_header

Time: ✅ 6.540µs (SLO: <10.000µs 📉 -34.6%) vs baseline: +0.1%

Memory: ✅ 34.898MB (SLO: <35.500MB 🟡 -1.7%) vs baseline: +4.6%

✅ wsgi_invalid_trace_id_header

Time: ✅ 6.681µs (SLO: <10.000µs 📉 -33.2%) vs baseline: +1.9%

Memory: ✅ 34.878MB (SLO: <35.500MB 🟡 -1.8%) vs baseline: +4.6%

✅ wsgi_large_header_no_matches

Time: ✅ 28.761µs (SLO: <40.000µs 📉 -28.1%) vs baseline: +0.3%

Memory: ✅ 34.977MB (SLO: <35.500MB 🟡 -1.5%) vs baseline: +4.9%

✅ wsgi_large_valid_headers_all

Time: ✅ 29.764µs (SLO: <40.000µs 📉 -25.6%) vs baseline: +0.2%

Memory: ✅ 34.937MB (SLO: <35.500MB 🟡 -1.6%) vs baseline: +4.6%

✅ wsgi_medium_header_no_matches

Time: ✅ 10.055µs (SLO: <20.000µs 📉 -49.7%) vs baseline: -0.3%

Memory: ✅ 35.016MB (SLO: <35.500MB 🟡 -1.4%) vs baseline: +5.0%

✅ wsgi_medium_valid_headers_all

Time: ✅ 11.559µs (SLO: <20.000µs 📉 -42.2%) vs baseline: +0.7%

Memory: ✅ 35.016MB (SLO: <35.500MB 🟡 -1.4%) vs baseline: +5.0%

✅ wsgi_valid_headers_all

Time: ✅ 6.553µs (SLO: <10.000µs 📉 -34.5%) vs baseline: +0.6%

Memory: ✅ 34.918MB (SLO: <35.500MB 🟡 -1.6%) vs baseline: +4.9%

✅ wsgi_valid_headers_basic

Time: ✅ 6.150µs (SLO: <10.000µs 📉 -38.5%) vs baseline: +1.7%

Memory: ✅ 34.878MB (SLO: <35.500MB 🟡 -1.8%) vs baseline: +4.6%

🟡 httppropagationinject - 16/16

✅ ids_only

Time: ✅ 22.054µs (SLO: <30.000µs 📉 -26.5%) vs baseline: +5.0%

Memory: ✅ 34.859MB (SLO: <35.500MB 🟡 -1.8%) vs baseline: +4.6%

✅ with_all

Time: ✅ 27.747µs (SLO: <40.000µs 📉 -30.6%) vs baseline: -0.2%

Memory: ✅ 34.918MB (SLO: <35.500MB 🟡 -1.6%) vs baseline: +4.8%

✅ with_dd_origin

Time: ✅ 24.808µs (SLO: <30.000µs 📉 -17.3%) vs baseline: +0.7%

Memory: ✅ 34.937MB (SLO: <35.500MB 🟡 -1.6%) vs baseline: +5.1%

✅ with_priority_and_origin

Time: ✅ 24.151µs (SLO: <40.000µs 📉 -39.6%) vs baseline: +0.2%

Memory: ✅ 34.918MB (SLO: <35.500MB 🟡 -1.6%) vs baseline: +4.9%

✅ with_sampling_priority

Time: ✅ 20.958µs (SLO: <30.000µs 📉 -30.1%) vs baseline: -0.4%

Memory: ✅ 34.878MB (SLO: <35.500MB 🟡 -1.8%) vs baseline: +4.4%

✅ with_tags

Time: ✅ 26.033µs (SLO: <40.000µs 📉 -34.9%) vs baseline: -0.3%

Memory: ✅ 34.918MB (SLO: <35.500MB 🟡 -1.6%) vs baseline: +5.2%

✅ with_tags_invalid

Time: ✅ 27.455µs (SLO: <40.000µs 📉 -31.4%) vs baseline: -0.6%

Memory: ✅ 34.918MB (SLO: <35.500MB 🟡 -1.6%) vs baseline: +4.7%

✅ with_tags_max_size

Time: ✅ 26.463µs (SLO: <40.000µs 📉 -33.8%) vs baseline: -0.4%

Memory: ✅ 34.977MB (SLO: <35.500MB 🟡 -1.5%) vs baseline: +5.0%

🟡 iastaspectssplit - 12/12

✅ rsplit_aspect

Time: ✅ 1.622µs (SLO: <10.000µs 📉 -83.8%) vs baseline: +6.1%

Memory: ✅ 42.644MB (SLO: <43.500MB 🟡 -2.0%) vs baseline: +5.1%

✅ rsplit_noaspect

Time: ✅ 1.645µs (SLO: <10.000µs 📉 -83.5%) vs baseline: +0.3%

Memory: ✅ 42.585MB (SLO: <43.500MB -2.1%) vs baseline: +4.8%

✅ split_aspect

Time: ✅ 1.568µs (SLO: <10.000µs 📉 -84.3%) vs baseline: +1.4%

Memory: ✅ 42.625MB (SLO: <43.500MB -2.0%) vs baseline: +5.1%

✅ split_noaspect

Time: ✅ 1.610µs (SLO: <10.000µs 📉 -83.9%) vs baseline: ~same

Memory: ✅ 42.585MB (SLO: <43.500MB -2.1%) vs baseline: +4.9%

✅ splitlines_aspect

Time: ✅ 1.515µs (SLO: <10.000µs 📉 -84.8%) vs baseline: +1.5%

Memory: ✅ 42.526MB (SLO: <43.500MB -2.2%) vs baseline: +4.6%

✅ splitlines_noaspect

Time: ✅ 1.554µs (SLO: <10.000µs 📉 -84.5%) vs baseline: ~same

Memory: ✅ 42.566MB (SLO: <43.500MB -2.1%) vs baseline: +4.8%

🟡 otelspan - 22/22

✅ add-event

Time: ✅ 40.134ms (SLO: <47.150ms 📉 -14.9%) vs baseline: ~same

Memory: ✅ 39.507MB (SLO: <47.000MB 📉 -15.9%) vs baseline: +4.9%

✅ add-metrics

Time: ✅ 260.072ms (SLO: <344.800ms 📉 -24.6%) vs baseline: -0.9%

Memory: ✅ 43.716MB (SLO: <47.500MB -8.0%) vs baseline: +4.8%

✅ add-tags

Time: ✅ 318.344ms (SLO: <321.000ms 🟡 -0.8%) vs baseline: +0.6%

Memory: ✅ 43.835MB (SLO: <47.500MB -7.7%) vs baseline: +4.9%

✅ get-context

Time: ✅ 80.420ms (SLO: <92.350ms 📉 -12.9%) vs baseline: ~same

Memory: ✅ 39.976MB (SLO: <46.500MB 📉 -14.0%) vs baseline: +5.0%

✅ is-recording

Time: ✅ 37.722ms (SLO: <44.500ms 📉 -15.2%) vs baseline: -0.2%

Memory: ✅ 39.544MB (SLO: <47.500MB 📉 -16.7%) vs baseline: +5.0%

✅ record-exception

Time: ✅ 58.925ms (SLO: <67.650ms 📉 -12.9%) vs baseline: -0.2%

Memory: ✅ 39.933MB (SLO: <47.000MB 📉 -15.0%) vs baseline: +4.6%

✅ set-status

Time: ✅ 44.065ms (SLO: <50.400ms 📉 -12.6%) vs baseline: -0.5%

Memory: ✅ 39.452MB (SLO: <47.000MB 📉 -16.1%) vs baseline: +4.8%

✅ start

Time: ✅ 37.813ms (SLO: <43.450ms 📉 -13.0%) vs baseline: +2.0%

Memory: ✅ 39.610MB (SLO: <47.000MB 📉 -15.7%) vs baseline: +5.4%

✅ start-finish

Time: ✅ 82.984ms (SLO: <88.000ms -5.7%) vs baseline: ~same

Memory: ✅ 37.395MB (SLO: <46.500MB 📉 -19.6%) vs baseline: +4.9%

✅ start-finish-telemetry

Time: ✅ 84.488ms (SLO: <89.000ms -5.1%) vs baseline: ~same

Memory: ✅ 37.316MB (SLO: <46.500MB 📉 -19.8%) vs baseline: +4.6%

✅ update-name

Time: ✅ 38.786ms (SLO: <45.150ms 📉 -14.1%) vs baseline: +0.1%

Memory: ✅ 39.504MB (SLO: <47.000MB 📉 -15.9%) vs baseline: +4.7%

🟡 ratelimiter - 12/12

✅ defaults

Time: ✅ 2.349µs (SLO: <10.000µs 📉 -76.5%) vs baseline: -0.2%

Memory: ✅ 35.095MB (SLO: <35.500MB 🟡 -1.1%) vs baseline: +4.7%

✅ high_rate_limit

Time: ✅ 2.390µs (SLO: <10.000µs 📉 -76.1%) vs baseline: -0.5%

Memory: ✅ 35.134MB (SLO: <35.500MB 🟡 -1.0%) vs baseline: +4.9%

✅ long_window

Time: ✅ 2.374µs (SLO: <10.000µs 📉 -76.3%) vs baseline: +0.6%

Memory: ✅ 35.114MB (SLO: <35.500MB 🟡 -1.1%) vs baseline: +5.0%

✅ low_rate_limit

Time: ✅ 2.365µs (SLO: <10.000µs 📉 -76.4%) vs baseline: +0.6%

Memory: ✅ 35.173MB (SLO: <35.500MB 🟡 -0.9%) vs baseline: +4.8%

✅ no_rate_limit

Time: ✅ 0.838µs (SLO: <10.000µs 📉 -91.6%) vs baseline: +1.6%

Memory: ✅ 35.114MB (SLO: <35.500MB 🟡 -1.1%) vs baseline: +4.8%

✅ short_window

Time: ✅ 2.492µs (SLO: <10.000µs 📉 -75.1%) vs baseline: -0.6%

Memory: ✅ 35.154MB (SLO: <35.500MB 🟡 -1.0%) vs baseline: +4.9%

🟡 recursivecomputation - 8/8

✅ deep

Time: ✅ 308.559ms (SLO: <320.950ms -3.9%) vs baseline: ~same

Memory: ✅ 36.019MB (SLO: <36.500MB 🟡 -1.3%) vs baseline: +4.6%

✅ deep-profiled

Time: ✅ 314.579ms (SLO: <359.150ms 📉 -12.4%) vs baseline: -0.3%

Memory: ✅ 39.892MB (SLO: <40.500MB 🟡 -1.5%) vs baseline: +5.2%

✅ medium

Time: ✅ 6.987ms (SLO: <7.400ms -5.6%) vs baseline: -0.1%

Memory: ✅ 34.800MB (SLO: <35.500MB 🟡 -2.0%) vs baseline: +4.7%

✅ shallow

Time: ✅ 0.945ms (SLO: <1.050ms -10.0%) vs baseline: +0.9%

Memory: ✅ 34.996MB (SLO: <35.500MB 🟡 -1.4%) vs baseline: +5.5%

🟡 samplingrules - 8/8

✅ average_match

Time: ✅ 137.057µs (SLO: <290.000µs 📉 -52.7%) vs baseline: -0.9%

Memory: ✅ 34.819MB (SLO: <35.500MB 🟡 -1.9%) vs baseline: +5.0%

✅ high_match

Time: ✅ 173.107µs (SLO: <480.000µs 📉 -63.9%) vs baseline: -0.5%

Memory: ✅ 34.741MB (SLO: <35.500MB -2.1%) vs baseline: +4.6%

✅ low_match

Time: ✅ 98.809µs (SLO: <120.000µs 📉 -17.7%) vs baseline: +0.2%

Memory: ✅ 603.629MB (SLO: <700.000MB 📉 -13.8%) vs baseline: +4.8%

✅ very_low_match

Time: ✅ 2.663ms (SLO: <8.500ms 📉 -68.7%) vs baseline: ~same

Memory: ✅ 71.057MB (SLO: <75.000MB -5.3%) vs baseline: +4.7%

🟡 sethttpmeta - 32/32

✅ all-disabled

Time: ✅ 10.571µs (SLO: <20.000µs 📉 -47.1%) vs baseline: +0.6%

Memory: ✅ 35.606MB (SLO: <36.000MB 🟡 -1.1%) vs baseline: +4.5%

✅ all-enabled

Time: ✅ 41.049µs (SLO: <50.000µs 📉 -17.9%) vs baseline: +2.5%

Memory: ✅ 35.645MB (SLO: <36.000MB 🟡 -1.0%) vs baseline: +4.9%

✅ collectipvariant_exists

Time: ✅ 40.796µs (SLO: <50.000µs 📉 -18.4%) vs baseline: -0.4%

Memory: ✅ 35.704MB (SLO: <36.000MB 🟡 -0.8%) vs baseline: +5.1%

✅ no-collectipvariant

Time: ✅ 40.170µs (SLO: <50.000µs 📉 -19.7%) vs baseline: +0.2%

Memory: ✅ 35.704MB (SLO: <36.000MB 🟡 -0.8%) vs baseline: +5.0%

✅ no-useragentvariant

Time: ✅ 38.634µs (SLO: <50.000µs 📉 -22.7%) vs baseline: -0.9%

Memory: ✅ 35.586MB (SLO: <36.000MB 🟡 -1.1%) vs baseline: +4.6%

✅ obfuscation-no-query

Time: ✅ 40.391µs (SLO: <50.000µs 📉 -19.2%) vs baseline: -0.7%

Memory: ✅ 35.684MB (SLO: <36.000MB 🟡 -0.9%) vs baseline: +4.6%

✅ obfuscation-regular-case-explicit-query

Time: ✅ 76.114µs (SLO: <90.000µs 📉 -15.4%) vs baseline: +0.2%

Memory: ✅ 35.625MB (SLO: <36.500MB -2.4%) vs baseline: +4.4%

✅ obfuscation-regular-case-implicit-query

Time: ✅ 76.715µs (SLO: <90.000µs 📉 -14.8%) vs baseline: +0.1%

Memory: ✅ 35.684MB (SLO: <36.500MB -2.2%) vs baseline: +4.7%

✅ obfuscation-send-querystring-disabled

Time: ✅ 154.501µs (SLO: <170.000µs -9.1%) vs baseline: +0.4%

Memory: ✅ 35.665MB (SLO: <36.500MB -2.3%) vs baseline: +4.6%

✅ obfuscation-worst-case-explicit-query

Time: ✅ 148.748µs (SLO: <160.000µs -7.0%) vs baseline: +0.4%

Memory: ✅ 35.665MB (SLO: <36.500MB -2.3%) vs baseline: +4.9%

✅ obfuscation-worst-case-implicit-query

Time: ✅ 155.156µs (SLO: <170.000µs -8.7%) vs baseline: +0.3%

Memory: ✅ 35.704MB (SLO: <36.500MB -2.2%) vs baseline: +4.7%

✅ useragentvariant_exists_1

Time: ✅ 39.593µs (SLO: <50.000µs 📉 -20.8%) vs baseline: -0.4%

Memory: ✅ 35.704MB (SLO: <36.000MB 🟡 -0.8%) vs baseline: +4.6%

✅ useragentvariant_exists_2

Time: ✅ 40.506µs (SLO: <50.000µs 📉 -19.0%) vs baseline: -0.2%

Memory: ✅ 35.743MB (SLO: <36.000MB 🟡 -0.7%) vs baseline: +5.0%

✅ useragentvariant_exists_3

Time: ✅ 39.976µs (SLO: <50.000µs 📉 -20.0%) vs baseline: ~same

Memory: ✅ 35.724MB (SLO: <36.000MB 🟡 -0.8%) vs baseline: +5.0%

✅ useragentvariant_not_exists_1

Time: ✅ 39.525µs (SLO: <50.000µs 📉 -21.0%) vs baseline: -0.2%

Memory: ✅ 35.802MB (SLO: <36.000MB 🟡 -0.5%) vs baseline: +5.2%

✅ useragentvariant_not_exists_2

Time: ✅ 39.479µs (SLO: <50.000µs 📉 -21.0%) vs baseline: ~same

Memory: ✅ 35.566MB (SLO: <36.000MB 🟡 -1.2%) vs baseline: +4.6%

🟡 span - 26/26

✅ add-event

Time: ✅ 18.239ms (SLO: <22.500ms 📉 -18.9%) vs baseline: +0.6%

Memory: ✅ 36.929MB (SLO: <53.000MB 📉 -30.3%) vs baseline: +4.9%

✅ add-metrics

Time: ✅ 88.502ms (SLO: <93.500ms -5.3%) vs baseline: +0.2%

Memory: ✅ 41.050MB (SLO: <53.000MB 📉 -22.5%) vs baseline: +4.4%

✅ add-tags

Time: ✅ 141.543ms (SLO: <155.000ms -8.7%) vs baseline: ~same

Memory: ✅ 41.192MB (SLO: <53.000MB 📉 -22.3%) vs baseline: +5.3%

✅ get-context

Time: ✅ 17.032ms (SLO: <20.500ms 📉 -16.9%) vs baseline: +1.0%

Memory: ✅ 36.717MB (SLO: <53.000MB 📉 -30.7%) vs baseline: +4.6%

✅ is-recording

Time: ✅ 17.372ms (SLO: <20.500ms 📉 -15.3%) vs baseline: +0.9%

Memory: ✅ 36.758MB (SLO: <53.000MB 📉 -30.6%) vs baseline: +4.7%

✅ record-exception

Time: ✅ 36.469ms (SLO: <40.000ms -8.8%) vs baseline: -0.3%

Memory: ✅ 37.354MB (SLO: <53.000MB 📉 -29.5%) vs baseline: +5.1%

✅ set-status

Time: ✅ 18.667ms (SLO: <22.000ms 📉 -15.1%) vs baseline: +0.2%

Memory: ✅ 36.775MB (SLO: <53.000MB 📉 -30.6%) vs baseline: +4.8%

✅ start

Time: ✅ 17.365ms (SLO: <20.500ms 📉 -15.3%) vs baseline: +3.1%

Memory: ✅ 36.817MB (SLO: <53.000MB 📉 -30.5%) vs baseline: +5.3%

✅ start-finish

Time: ✅ 51.315ms (SLO: <52.500ms -2.3%) vs baseline: +0.4%

Memory: ✅ 34.839MB (SLO: <35.500MB 🟡 -1.9%) vs baseline: +4.9%

✅ start-finish-telemetry

Time: ✅ 52.233ms (SLO: <54.500ms -4.2%) vs baseline: +0.1%

Memory: ✅ 34.898MB (SLO: <35.500MB 🟡 -1.7%) vs baseline: +4.9%

✅ start-finish-traceid128

Time: ✅ 54.132ms (SLO: <57.000ms -5.0%) vs baseline: ~same

Memory: ✅ 34.898MB (SLO: <35.500MB 🟡 -1.7%) vs baseline: +5.4%

✅ start-traceid128

Time: ✅ 17.389ms (SLO: <22.500ms 📉 -22.7%) vs baseline: +1.0%

Memory: ✅ 36.781MB (SLO: <53.000MB 📉 -30.6%) vs baseline: +4.8%

✅ update-name

Time: ✅ 17.376ms (SLO: <22.000ms 📉 -21.0%) vs baseline: +0.7%

Memory: ✅ 36.776MB (SLO: <53.000MB 📉 -30.6%) vs baseline: +4.6%

🟡 tracer - 6/6

✅ large

Time: ✅ 29.197ms (SLO: <32.950ms 📉 -11.4%) vs baseline: +0.5%

Memory: ✅ 35.901MB (SLO: <36.500MB 🟡 -1.6%) vs baseline: +4.7%

✅ medium

Time: ✅ 2.869ms (SLO: <3.200ms 📉 -10.4%) vs baseline: -0.5%

Memory: ✅ 34.937MB (SLO: <35.500MB 🟡 -1.6%) vs baseline: +5.4%

✅ small

Time: ✅ 330.379µs (SLO: <370.000µs 📉 -10.7%) vs baseline: +1.0%

Memory: ✅ 34.819MB (SLO: <35.500MB 🟡 -1.9%) vs baseline: +5.0%

⚠️ Unstable Tests (1 suite)

⚠️

packagesupdateimporteddependencies - 24/24 (1 unstable)

✅ import_many

Time: ✅ 155.343µs (SLO: <170.000µs -8.6%) vs baseline: +0.4%

Memory: ✅ 40.434MB (SLO: <43.000MB -6.0%) vs baseline: +5.0%

✅ import_many_cached

Time: ✅ 120.663µs (SLO: <130.000µs -7.2%) vs baseline: -0.7%

Memory: ✅ 40.138MB (SLO: <43.000MB -6.7%) vs baseline: +5.1%

✅ import_many_stdlib

Time: ✅ 0.759ms (SLO: <1.750ms 📉 -56.6%) vs baseline: +0.8%

Memory: ✅ 40.127MB (SLO: <43.000MB -6.7%) vs baseline: +4.8%

⚠️ import_many_stdlib_cached

Time: ⚠️ 0.172ms (SLO: <1.100ms 📉 -84.3%) vs baseline: +0.1%

Memory: ✅ 39.891MB (SLO: <43.000MB -7.2%) vs baseline: +4.3%

✅ import_many_unknown

Time: ✅ 829.410µs (SLO: <890.000µs -6.8%) vs baseline: -0.3%

Memory: ✅ 40.151MB (SLO: <43.000MB -6.6%) vs baseline: +4.8%

✅ import_many_unknown_cached

Time: ✅ 791.828µs (SLO: <870.000µs -9.0%) vs baseline: -0.2%

Memory: ✅ 40.140MB (SLO: <43.000MB -6.7%) vs baseline: +4.6%

✅ import_one

Time: ✅ 19.836µs (SLO: <30.000µs 📉 -33.9%) vs baseline: +0.3%

Memory: ✅ 40.237MB (SLO: <43.000MB -6.4%) vs baseline: +4.5%

✅ import_one_cache

Time: ✅ 6.312µs (SLO: <10.000µs 📉 -36.9%) vs baseline: +0.4%

Memory: ✅ 40.083MB (SLO: <43.000MB -6.8%) vs baseline: +5.1%

✅ import_one_stdlib

Time: ✅ 18.732µs (SLO: <20.000µs -6.3%) vs baseline: ~same

Memory: ✅ 40.184MB (SLO: <43.000MB -6.5%) vs baseline: +4.9%

✅ import_one_stdlib_cache

Time: ✅ 6.259µs (SLO: <10.000µs 📉 -37.4%) vs baseline: -0.9%

Memory: ✅ 40.120MB (SLO: <43.000MB -6.7%) vs baseline: +5.1%

✅ import_one_unknown

Time: ✅ 45.491µs (SLO: <50.000µs -9.0%) vs baseline: +0.3%

Memory: ✅ 40.125MB (SLO: <43.000MB -6.7%) vs baseline: +5.3%

✅ import_one_unknown_cache

Time: ✅ 6.325µs (SLO: <10.000µs 📉 -36.7%) vs baseline: +0.4%

Memory: ✅ 40.154MB (SLO: <43.000MB -6.6%) vs baseline: +5.2%

✅ All Tests Passing (4 suites)

✅ iast_aspects - 40/40

✅ re_expand_aspect

Time: ✅ 37.504µs (SLO: <40.000µs -6.2%) vs baseline: +6.3%

Memory: ✅ 42.172MB (SLO: <43.500MB -3.1%) vs baseline: +4.5%

✅ re_expand_noaspect

Time: ✅ 35.058µs (SLO: <40.000µs 📉 -12.4%) vs baseline: -0.9%

Memory: ✅ 42.251MB (SLO: <43.500MB -2.9%) vs baseline: +4.9%

✅ re_findall_aspect

Time: ✅ 3.406µs (SLO: <10.000µs 📉 -65.9%) vs baseline: -0.5%

Memory: ✅ 42.290MB (SLO: <43.500MB -2.8%) vs baseline: +5.2%

✅ re_findall_noaspect

Time: ✅ 3.282µs (SLO: <10.000µs 📉 -67.2%) vs baseline: +1.8%

Memory: ✅ 42.290MB (SLO: <43.500MB -2.8%) vs baseline: +4.7%

✅ re_finditer_aspect

Time: ✅ 4.538µs (SLO: <10.000µs 📉 -54.6%) vs baseline: -0.4%

Memory: ✅ 42.428MB (SLO: <43.500MB -2.5%) vs baseline: +5.2%

✅ re_finditer_noaspect

Time: ✅ 3.298µs (SLO: <10.000µs 📉 -67.0%) vs baseline: -0.6%

Memory: ✅ 42.251MB (SLO: <43.500MB -2.9%) vs baseline: +4.7%

✅ re_fullmatch_aspect

Time: ✅ 2.810µs (SLO: <10.000µs 📉 -71.9%) vs baseline: -0.3%

Memory: ✅ 42.192MB (SLO: <43.500MB -3.0%) vs baseline: +4.5%

✅ re_fullmatch_noaspect

Time: ✅ 3.103µs (SLO: <10.000µs 📉 -69.0%) vs baseline: +0.9%

Memory: ✅ 42.330MB (SLO: <43.500MB -2.7%) vs baseline: +5.1%

✅ re_group_aspect

Time: ✅ 4.835µs (SLO: <10.000µs 📉 -51.7%) vs baseline: +0.3%

Memory: ✅ 42.310MB (SLO: <43.500MB -2.7%) vs baseline: +5.0%

✅ re_group_noaspect

Time: ✅ 4.892µs (SLO: <10.000µs 📉 -51.1%) vs baseline: -0.1%

Memory: ✅ 42.271MB (SLO: <43.500MB -2.8%) vs baseline: +4.9%

✅ re_groups_aspect

Time: ✅ 4.983µs (SLO: <10.000µs 📉 -50.2%) vs baseline: +0.1%

Memory: ✅ 42.212MB (SLO: <43.500MB -3.0%) vs baseline: +4.9%

✅ re_groups_noaspect

Time: ✅ 5.000µs (SLO: <10.000µs 📉 -50.0%) vs baseline: +1.0%

Memory: ✅ 42.192MB (SLO: <43.500MB -3.0%) vs baseline: +4.8%

✅ re_match_aspect

Time: ✅ 2.811µs (SLO: <10.000µs 📉 -71.9%) vs baseline: +0.1%

Memory: ✅ 42.310MB (SLO: <43.500MB -2.7%) vs baseline: +4.8%

✅ re_match_noaspect

Time: ✅ 3.099µs (SLO: <10.000µs 📉 -69.0%) vs baseline: -0.4%

Memory: ✅ 42.310MB (SLO: <43.500MB -2.7%) vs baseline: +4.7%

✅ re_search_aspect

Time: ✅ 2.656µs (SLO: <10.000µs 📉 -73.4%) vs baseline: ~same

Memory: ✅ 42.251MB (SLO: <43.500MB -2.9%) vs baseline: +4.2%

✅ re_search_noaspect

Time: ✅ 2.906µs (SLO: <10.000µs 📉 -70.9%) vs baseline: +0.3%

Memory: ✅ 42.349MB (SLO: <43.500MB -2.6%) vs baseline: +5.4%

✅ re_sub_aspect

Time: ✅ 3.581µs (SLO: <10.000µs 📉 -64.2%) vs baseline: +0.7%

Memory: ✅ 42.408MB (SLO: <43.500MB -2.5%) vs baseline: +5.2%

✅ re_sub_noaspect

Time: ✅ 4.041µs (SLO: <10.000µs 📉 -59.6%) vs baseline: +2.2%

Memory: ✅ 42.290MB (SLO: <43.500MB -2.8%) vs baseline: +5.1%

✅ re_subn_aspect

Time: ✅ 3.784µs (SLO: <10.000µs 📉 -62.2%) vs baseline: -0.6%

Memory: ✅ 42.172MB (SLO: <43.500MB -3.1%) vs baseline: +4.6%

✅ re_subn_noaspect

Time: ✅ 4.090µs (SLO: <10.000µs 📉 -59.1%) vs baseline: -0.6%

Memory: ✅ 42.153MB (SLO: <43.500MB -3.1%) vs baseline: +4.7%

✅ iastpropagation - 8/8

✅ no-propagation

Time: ✅ 49.181µs (SLO: <60.000µs 📉 -18.0%) vs baseline: -0.9%

Memory: ✅ 38.358MB (SLO: <42.000MB -8.7%) vs baseline: +5.0%

✅ propagation_enabled

Time: ✅ 137.211µs (SLO: <190.000µs 📉 -27.8%) vs baseline: -0.4%

Memory: ✅ 38.398MB (SLO: <42.000MB -8.6%) vs baseline: +5.0%

✅ propagation_enabled_100

Time: ✅ 1.590ms (SLO: <2.300ms 📉 -30.9%) vs baseline: +0.1%

Memory: ✅ 38.339MB (SLO: <42.000MB -8.7%) vs baseline: +4.7%

✅ propagation_enabled_1000

Time: ✅ 29.544ms (SLO: <34.550ms 📉 -14.5%) vs baseline: ~same

Memory: ✅ 38.594MB (SLO: <42.000MB -8.1%) vs baseline: +4.7%

✅ otelsdkspan - 24/24

✅ add-event

Time: ✅ 40.542ms (SLO: <42.000ms -3.5%) vs baseline: +0.4%

Memory: ✅ 37.493MB (SLO: <39.000MB -3.9%) vs baseline: +4.9%

✅ add-link

Time: ✅ 36.449ms (SLO: <38.550ms -5.5%) vs baseline: +0.1%

Memory: ✅ 37.395MB (SLO: <39.000MB -4.1%) vs baseline: +4.5%

✅ add-metrics

Time: ✅ 218.551ms (SLO: <232.000ms -5.8%) vs baseline: +0.1%

Memory: ✅ 37.473MB (SLO: <39.000MB -3.9%) vs baseline: +5.0%

✅ add-tags

Time: ✅ 210.416ms (SLO: <221.600ms -5.0%) vs baseline: -1.0%

Memory: ✅ 37.316MB (SLO: <39.000MB -4.3%) vs baseline: +3.9%

✅ get-context

Time: ✅ 29.234ms (SLO: <31.300ms -6.6%) vs baseline: +0.4%

Memory: ✅ 37.513MB (SLO: <39.000MB -3.8%) vs baseline: +5.0%

✅ is-recording

Time: ✅ 29.456ms (SLO: <31.000ms -5.0%) vs baseline: +0.8%

Memory: ✅ 37.493MB (SLO: <39.000MB -3.9%) vs baseline: +4.9%

✅ record-exception

Time: ✅ 63.204ms (SLO: <65.850ms -4.0%) vs baseline: +0.3%

Memory: ✅ 37.356MB (SLO: <39.000MB -4.2%) vs baseline: +3.9%

✅ set-status

Time: ✅ 31.841ms (SLO: <34.150ms -6.8%) vs baseline: -1.1%

Memory: ✅ 37.650MB (SLO: <39.000MB -3.5%) vs baseline: +4.9%

✅ start

Time: ✅ 29.315ms (SLO: <30.150ms -2.8%) vs baseline: +1.2%

Memory: ✅ 37.316MB (SLO: <39.000MB -4.3%) vs baseline: +3.5%

✅ start-finish

Time: ✅ 33.980ms (SLO: <35.350ms -3.9%) vs baseline: +0.7%

Memory: ✅ 37.493MB (SLO: <39.000MB -3.9%) vs baseline: +4.0%

✅ start-finish-telemetry

Time: ✅ 34.157ms (SLO: <35.450ms -3.6%) vs baseline: +0.4%

Memory: ✅ 37.375MB (SLO: <39.000MB -4.2%) vs baseline: +4.4%

✅ update-name

Time: ✅ 31.248ms (SLO: <33.400ms -6.4%) vs baseline: +0.5%

Memory: ✅ 37.316MB (SLO: <39.000MB -4.3%) vs baseline: +4.0%

✅ packagespackageforrootmodulemapping - 4/4

✅ cache_off

Time: ✅ 342.064ms (SLO: <354.300ms -3.5%) vs baseline: -0.8%

Memory: ✅ 41.344MB (SLO: <43.500MB -5.0%) vs baseline: +6.3%

✅ cache_on

Time: ✅ 0.385µs (SLO: <10.000µs 📉 -96.1%) vs baseline: -0.2%

Memory: ✅ 39.785MB (SLO: <43.000MB -7.5%) vs baseline: +5.3%

ℹ️ Scenarios Missing SLO Configuration (26 scenarios)

The following scenarios exist in candidate data but have no SLO thresholds configured:

coreapiscenario-core_dispatch_listeners
coreapiscenario-core_dispatch_no_listeners
coreapiscenario-core_dispatch_with_results_listeners
coreapiscenario-core_dispatch_with_results_no_listeners
djangosimple-baseline
errortrackingdjangosimple-baseline
errortrackingflasksqli-baseline
flasksimple-baseline
flasksqli-baseline
sethttpmeta-obfuscation-disabled
startup-baseline
startup-baseline_django
startup-baseline_flask
startup-ddtrace_run
startup-ddtrace_run_appsec
startup-ddtrace_run_profiling
startup-ddtrace_run_runtime_metrics
startup-ddtrace_run_send_span
startup-ddtrace_run_telemetry_disabled
startup-ddtrace_run_telemetry_enabled
startup-import_ddtrace
startup-import_ddtrace_auto
startup-import_ddtrace_auto_django
startup-import_ddtrace_auto_flask
startup-import_ddtrace_django
startup-import_ddtrace_flask

ddtrace/internal/datadog/profiling/stack/echion/echion/threads.h

r1viollet · 2025-12-28T23:44:53Z

Thank you for a great description.
I have a few minor concerns though I think the change is relevant and pragmatic.

r1viollet

LGTM

ddtrace/internal/datadog/profiling/stack/echion/echion/threads.h

## Description Related PRs - Related: #15712 - Dependent: #15789 - Research PR: https://github.com/DataDog/dd-trace-py/pull/15675/commits (if needed for code archeology...) ### What is this about? This PR updates the Task unwinding logic in the Profiler to (more) properly handle race conditions around running/"on CPU" Tasks. A Task can be either in a _running_ state (i.e. actively _computing_ something itself, like executing a regular Python function) or in a _sleeping_ state (i.e. waiting for something else to happen to wake up). <img width="1076" height="434" alt="image" src="https://github.com/user-attachments/assets/be6759eb-0255-43ef-b3ce-d47486bb653c" /> After those changes, this problem does not appear anymore: only Frames that are actually from the same Stack appear within a given Stack. <img width="1387" height="445" alt="image" src="https://github.com/user-attachments/assets/31287863-f918-47a8-a39b-b3a0d27dce8f" /> ### Why do we need it? Because we don't take a "snapshot of the whole Python process at once", there is a race condition in our Sampler. We first capture the Thread Stack (i.e. for the current Thread, if it is running, what Python code the interpreter is running), then for each Task in the Thread's Event Loop [if it exists] we look at the Task's own Stack. (Since Task/Coroutines are pausable, they have their own Stack that is kept in memory when they're paused, then re-loaded into context when they're resumed. Walking each Task's Stack allows us to e.g. know what code they're "running", even when they aren't actually currently running code...) Going back to the race condition question, we may have a discrepancy between what the Python Thread Stack tells us (what the interpreter is running) and what Task objects themselves tell us (because a tiny amount of time actually elapses between the moment we capture the Thread Stack and the moment we inspect the Task objects, so _what is happening_ may have changed in the meantime). I've already in the past gone into more detail regarding what buggy/unexpected behaviour may result from that race condition; this PR improves this. Note that there is a pretty obvious tradeoff here. When we detect a discrepancy, we can: - Ignore the fact we know something bad is going to happen – I'd rather not do that because it can look terrible for customers (and we don't want to look _obviously wrong_ to them). That would mean _quantity over quality_. - Try to recover by doing clever tricks (this can be somewhat costly because we have to interleave the various Stacks we have... I think we may want to do that at some point but not without putting more thought into it; plus those clever tricks can also sometimes be brittle tricks). That would mean _quality and quantity over cost_ (which in practice probably also means _quality over quantity_ because increasing costs will most probably lead to more adaptive sampling). - Give up and just pretend this never happened – skip that Sample (for the current Task, and in certain cases for the current Thread altogether). That would mean _quality over quantity_. For the time being, things can only get better because we're in a state where we don't deal with the problem at all. The current PR biases towards a mix: we detect more reliably the depth of the pure Python Stack (which allows us not to rely on un-unwinding Task Stacks), and then we skip Samples that we know will be bogus. If the latter happens sufficiently rarely [a claim I still need numbers to back] then this is OK. ### How does it work? The main problem we are trying to avoid here is having some of Task A's Frames appearing as part of Task B's Stack. Working around this requires properly splitting the Python Stack when it says it is running a Task, such that we only push the `asyncio` runtime Frames on top of each non-Task A Task. Walking the Python Stack allows us to do that properly. We thus walk the Python Stack (once per Thread) to detect whether we see `Handle.run` Frames – those indicate that the Event Loop is currently _stepping_ the Coroutine – in other words executing code. (When that happens, we expect at least one Task to be marked as _running_ (there could be more – that's also a race condition, but it's OK, as far as CPU Time is not concerned...)) As soon as we see a `run` Frame, we know the depth of the "pure Python Stack" and we can push it on top of every Task's Stack! ### What does this cost us? This is not completely free – we're doing more work (namely, walking the stack at each Sample). Looking at Full Host Profiles on a high-CPU `asyncio`-based Python script, I'm getting the following difference. Note that the total Profiler overhead is about 360ms/minute, meaning the additional ~20ms we're using here represent an extra 5% overhead. Given the importance of getting Stacks right (or at least not completely wrong), I'd say it's worth it, but it's still noticeable. I tried to do otherwise – but as far as I can tell, as long as the race condition between unwinding the Python Stack and unwinding Task Stacks exists (which it can't not), we will not be able to tell for sure how many pure Python Stack Frames we need to push. There are heuristics that can get us there in theoretically better time (e.g. only walk the Python Stack if all Tasks reported as non-running), but those come at a correctness and code readability cost, and it's not even that certain their overhead would be lesser. I also have another PR that should reduce the cost of unwinding Tasks (that uses the fact we now walk the Python Stack only once): #15789 so hopefully it evens things out. <img width="1926" height="921" alt="image" src="https://github.com/user-attachments/assets/e21a6698-2b18-43bb-aff9-4e8d59354332" />

## Description Related PRs - Related: #15712 - Dependent: #15789 - Research PR: https://github.com/DataDog/dd-trace-py/pull/15675/commits (if needed for code archeology...) ### What is this about? This PR updates the Task unwinding logic in the Profiler to (more) properly handle race conditions around running/"on CPU" Tasks. A Task can be either in a _running_ state (i.e. actively _computing_ something itself, like executing a regular Python function) or in a _sleeping_ state (i.e. waiting for something else to happen to wake up). <img width="1076" height="434" alt="image" src="https://github.com/user-attachments/assets/be6759eb-0255-43ef-b3ce-d47486bb653c" /> After those changes, this problem does not appear anymore: only Frames that are actually from the same Stack appear within a given Stack. <img width="1387" height="445" alt="image" src="https://github.com/user-attachments/assets/31287863-f918-47a8-a39b-b3a0d27dce8f" /> ### Why do we need it? Because we don't take a "snapshot of the whole Python process at once", there is a race condition in our Sampler. We first capture the Thread Stack (i.e. for the current Thread, if it is running, what Python code the interpreter is running), then for each Task in the Thread's Event Loop [if it exists] we look at the Task's own Stack. (Since Task/Coroutines are pausable, they have their own Stack that is kept in memory when they're paused, then re-loaded into context when they're resumed. Walking each Task's Stack allows us to e.g. know what code they're "running", even when they aren't actually currently running code...) Going back to the race condition question, we may have a discrepancy between what the Python Thread Stack tells us (what the interpreter is running) and what Task objects themselves tell us (because a tiny amount of time actually elapses between the moment we capture the Thread Stack and the moment we inspect the Task objects, so _what is happening_ may have changed in the meantime). I've already in the past gone into more detail regarding what buggy/unexpected behaviour may result from that race condition; this PR improves this. Note that there is a pretty obvious tradeoff here. When we detect a discrepancy, we can: - Ignore the fact we know something bad is going to happen – I'd rather not do that because it can look terrible for customers (and we don't want to look _obviously wrong_ to them). That would mean _quantity over quality_. - Try to recover by doing clever tricks (this can be somewhat costly because we have to interleave the various Stacks we have... I think we may want to do that at some point but not without putting more thought into it; plus those clever tricks can also sometimes be brittle tricks). That would mean _quality and quantity over cost_ (which in practice probably also means _quality over quantity_ because increasing costs will most probably lead to more adaptive sampling). - Give up and just pretend this never happened – skip that Sample (for the current Task, and in certain cases for the current Thread altogether). That would mean _quality over quantity_. For the time being, things can only get better because we're in a state where we don't deal with the problem at all. The current PR biases towards a mix: we detect more reliably the depth of the pure Python Stack (which allows us not to rely on un-unwinding Task Stacks), and then we skip Samples that we know will be bogus. If the latter happens sufficiently rarely [a claim I still need numbers to back] then this is OK. ### How does it work? The main problem we are trying to avoid here is having some of Task A's Frames appearing as part of Task B's Stack. Working around this requires properly splitting the Python Stack when it says it is running a Task, such that we only push the `asyncio` runtime Frames on top of each non-Task A Task. Walking the Python Stack allows us to do that properly. We thus walk the Python Stack (once per Thread) to detect whether we see `Handle.run` Frames – those indicate that the Event Loop is currently _stepping_ the Coroutine – in other words executing code. (When that happens, we expect at least one Task to be marked as _running_ (there could be more – that's also a race condition, but it's OK, as far as CPU Time is not concerned...)) As soon as we see a `run` Frame, we know the depth of the "pure Python Stack" and we can push it on top of every Task's Stack! ### What does this cost us? This is not completely free – we're doing more work (namely, walking the stack at each Sample). Looking at Full Host Profiles on a high-CPU `asyncio`-based Python script, I'm getting the following difference. Note that the total Profiler overhead is about 360ms/minute, meaning the additional ~20ms we're using here represent an extra 5% overhead. Given the importance of getting Stacks right (or at least not completely wrong), I'd say it's worth it, but it's still noticeable. I tried to do otherwise – but as far as I can tell, as long as the race condition between unwinding the Python Stack and unwinding Task Stacks exists (which it can't not), we will not be able to tell for sure how many pure Python Stack Frames we need to push. There are heuristics that can get us there in theoretically better time (e.g. only walk the Python Stack if all Tasks reported as non-running), but those come at a correctness and code readability cost, and it's not even that certain their overhead would be lesser. I also have another PR that should reduce the cost of unwinding Tasks (that uses the fact we now walk the Python Stack only once): #15789 so hopefully it evens things out. <img width="1926" height="921" alt="image" src="https://github.com/user-attachments/assets/e21a6698-2b18-43bb-aff9-4e8d59354332" /> (cherry picked from commit 61b1799)

…15854) Backport 61b1799 from #15780 to 4.1. ## Description Related PRs - Related: #15712 - Dependent: #15789 - Research PR: https://github.com/DataDog/dd-trace-py/pull/15675/commits (if needed for code archeology...) ### What is this about? This PR updates the Task unwinding logic in the Profiler to (more) properly handle race conditions around running/"on CPU" Tasks. A Task can be either in a _running_ state (i.e. actively _computing_ something itself, like executing a regular Python function) or in a _sleeping_ state (i.e. waiting for something else to happen to wake up). <img width="1076" height="434" alt="image" src="https://github.com/user-attachments/assets/be6759eb-0255-43ef-b3ce-d47486bb653c" /> After those changes, this problem does not appear anymore: only Frames that are actually from the same Stack appear within a given Stack. <img width="1387" height="445" alt="image" src="https://github.com/user-attachments/assets/31287863-f918-47a8-a39b-b3a0d27dce8f" /> ### Why do we need it? Because we don't take a "snapshot of the whole Python process at once", there is a race condition in our Sampler. We first capture the Thread Stack (i.e. for the current Thread, if it is running, what Python code the interpreter is running), then for each Task in the Thread's Event Loop [if it exists] we look at the Task's own Stack. (Since Task/Coroutines are pausable, they have their own Stack that is kept in memory when they're paused, then re-loaded into context when they're resumed. Walking each Task's Stack allows us to e.g. know what code they're "running", even when they aren't actually currently running code...) Going back to the race condition question, we may have a discrepancy between what the Python Thread Stack tells us (what the interpreter is running) and what Task objects themselves tell us (because a tiny amount of time actually elapses between the moment we capture the Thread Stack and the moment we inspect the Task objects, so _what is happening_ may have changed in the meantime). I've already in the past gone into more detail regarding what buggy/unexpected behaviour may result from that race condition; this PR improves this. Note that there is a pretty obvious tradeoff here. When we detect a discrepancy, we can: - Ignore the fact we know something bad is going to happen – I'd rather not do that because it can look terrible for customers (and we don't want to look _obviously wrong_ to them). That would mean _quantity over quality_. - Try to recover by doing clever tricks (this can be somewhat costly because we have to interleave the various Stacks we have... I think we may want to do that at some point but not without putting more thought into it; plus those clever tricks can also sometimes be brittle tricks). That would mean _quality and quantity over cost_ (which in practice probably also means _quality over quantity_ because increasing costs will most probably lead to more adaptive sampling). - Give up and just pretend this never happened – skip that Sample (for the current Task, and in certain cases for the current Thread altogether). That would mean _quality over quantity_. For the time being, things can only get better because we're in a state where we don't deal with the problem at all. The current PR biases towards a mix: we detect more reliably the depth of the pure Python Stack (which allows us not to rely on un-unwinding Task Stacks), and then we skip Samples that we know will be bogus. If the latter happens sufficiently rarely [a claim I still need numbers to back] then this is OK. ### How does it work? The main problem we are trying to avoid here is having some of Task A's Frames appearing as part of Task B's Stack. Working around this requires properly splitting the Python Stack when it says it is running a Task, such that we only push the `asyncio` runtime Frames on top of each non-Task A Task. Walking the Python Stack allows us to do that properly. We thus walk the Python Stack (once per Thread) to detect whether we see `Handle.run` Frames – those indicate that the Event Loop is currently _stepping_ the Coroutine – in other words executing code. (When that happens, we expect at least one Task to be marked as _running_ (there could be more – that's also a race condition, but it's OK, as far as CPU Time is not concerned...)) As soon as we see a `run` Frame, we know the depth of the "pure Python Stack" and we can push it on top of every Task's Stack! ### What does this cost us? This is not completely free – we're doing more work (namely, walking the stack at each Sample). Looking at Full Host Profiles on a high-CPU `asyncio`-based Python script, I'm getting the following difference. Note that the total Profiler overhead is about 360ms/minute, meaning the additional ~20ms we're using here represent an extra 5% overhead. Given the importance of getting Stacks right (or at least not completely wrong), I'd say it's worth it, but it's still noticeable. I tried to do otherwise – but as far as I can tell, as long as the race condition between unwinding the Python Stack and unwinding Task Stacks exists (which it can't not), we will not be able to tell for sure how many pure Python Stack Frames we need to push. There are heuristics that can get us there in theoretically better time (e.g. only walk the Python Stack if all Tasks reported as non-running), but those come at a correctness and code readability cost, and it's not even that certain their overhead would be lesser. I also have another PR that should reduce the cost of unwinding Tasks (that uses the fact we now walk the Python Stack only once): #15789 so hopefully it evens things out. <img width="1926" height="921" alt="image" src="https://github.com/user-attachments/assets/e21a6698-2b18-43bb-aff9-4e8d59354332" /> Co-authored-by: Thomas Kowalski <thomas.kowalski@datadoghq.com>

) ## Description Related PRs - Related: DataDog#15712 - Dependent: DataDog#15789 - Research PR: https://github.com/DataDog/dd-trace-py/pull/15675/commits (if needed for code archeology...) ### What is this about? This PR updates the Task unwinding logic in the Profiler to (more) properly handle race conditions around running/"on CPU" Tasks. A Task can be either in a _running_ state (i.e. actively _computing_ something itself, like executing a regular Python function) or in a _sleeping_ state (i.e. waiting for something else to happen to wake up). <img width="1076" height="434" alt="image" src="https://github.com/user-attachments/assets/be6759eb-0255-43ef-b3ce-d47486bb653c" /> After those changes, this problem does not appear anymore: only Frames that are actually from the same Stack appear within a given Stack. <img width="1387" height="445" alt="image" src="https://github.com/user-attachments/assets/31287863-f918-47a8-a39b-b3a0d27dce8f" /> ### Why do we need it? Because we don't take a "snapshot of the whole Python process at once", there is a race condition in our Sampler. We first capture the Thread Stack (i.e. for the current Thread, if it is running, what Python code the interpreter is running), then for each Task in the Thread's Event Loop [if it exists] we look at the Task's own Stack. (Since Task/Coroutines are pausable, they have their own Stack that is kept in memory when they're paused, then re-loaded into context when they're resumed. Walking each Task's Stack allows us to e.g. know what code they're "running", even when they aren't actually currently running code...) Going back to the race condition question, we may have a discrepancy between what the Python Thread Stack tells us (what the interpreter is running) and what Task objects themselves tell us (because a tiny amount of time actually elapses between the moment we capture the Thread Stack and the moment we inspect the Task objects, so _what is happening_ may have changed in the meantime). I've already in the past gone into more detail regarding what buggy/unexpected behaviour may result from that race condition; this PR improves this. Note that there is a pretty obvious tradeoff here. When we detect a discrepancy, we can: - Ignore the fact we know something bad is going to happen – I'd rather not do that because it can look terrible for customers (and we don't want to look _obviously wrong_ to them). That would mean _quantity over quality_. - Try to recover by doing clever tricks (this can be somewhat costly because we have to interleave the various Stacks we have... I think we may want to do that at some point but not without putting more thought into it; plus those clever tricks can also sometimes be brittle tricks). That would mean _quality and quantity over cost_ (which in practice probably also means _quality over quantity_ because increasing costs will most probably lead to more adaptive sampling). - Give up and just pretend this never happened – skip that Sample (for the current Task, and in certain cases for the current Thread altogether). That would mean _quality over quantity_. For the time being, things can only get better because we're in a state where we don't deal with the problem at all. The current PR biases towards a mix: we detect more reliably the depth of the pure Python Stack (which allows us not to rely on un-unwinding Task Stacks), and then we skip Samples that we know will be bogus. If the latter happens sufficiently rarely [a claim I still need numbers to back] then this is OK. ### How does it work? The main problem we are trying to avoid here is having some of Task A's Frames appearing as part of Task B's Stack. Working around this requires properly splitting the Python Stack when it says it is running a Task, such that we only push the `asyncio` runtime Frames on top of each non-Task A Task. Walking the Python Stack allows us to do that properly. We thus walk the Python Stack (once per Thread) to detect whether we see `Handle.run` Frames – those indicate that the Event Loop is currently _stepping_ the Coroutine – in other words executing code. (When that happens, we expect at least one Task to be marked as _running_ (there could be more – that's also a race condition, but it's OK, as far as CPU Time is not concerned...)) As soon as we see a `run` Frame, we know the depth of the "pure Python Stack" and we can push it on top of every Task's Stack! ### What does this cost us? This is not completely free – we're doing more work (namely, walking the stack at each Sample). Looking at Full Host Profiles on a high-CPU `asyncio`-based Python script, I'm getting the following difference. Note that the total Profiler overhead is about 360ms/minute, meaning the additional ~20ms we're using here represent an extra 5% overhead. Given the importance of getting Stacks right (or at least not completely wrong), I'd say it's worth it, but it's still noticeable. I tried to do otherwise – but as far as I can tell, as long as the race condition between unwinding the Python Stack and unwinding Task Stacks exists (which it can't not), we will not be able to tell for sure how many pure Python Stack Frames we need to push. There are heuristics that can get us there in theoretically better time (e.g. only walk the Python Stack if all Tasks reported as non-running), but those come at a correctness and code readability cost, and it's not even that certain their overhead would be lesser. I also have another PR that should reduce the cost of unwinding Tasks (that uses the fact we now walk the Python Stack only once): DataDog#15789 so hopefully it evens things out. <img width="1926" height="921" alt="image" src="https://github.com/user-attachments/assets/e21a6698-2b18-43bb-aff9-4e8d59354332" />

KowalskiThomas force-pushed the kowalski/fix-profiling-workaround-for-on-cpu-task-race-condition-fix-reboot branch from e91a64f to 119355b Compare December 24, 2025 06:25

KowalskiThomas changed the title ~~fix(profiling): workaround for on-CPU Task race condition~~ fix(profiling): workaround for on-CPU madness Dec 24, 2025

KowalskiThomas force-pushed the kowalski/fix-profiling-workaround-for-on-cpu-task-race-condition-fix-reboot branch from 119355b to 97d6e31 Compare December 24, 2025 09:23

KowalskiThomas added the changelog/no-changelog A changelog entry is not required for this PR. label Dec 24, 2025

KowalskiThomas force-pushed the kowalski/fix-profiling-workaround-for-on-cpu-task-race-condition-fix-reboot branch from 97d6e31 to 687aa2c Compare December 24, 2025 15:11

KowalskiThomas removed the changelog/no-changelog A changelog entry is not required for this PR. label Dec 24, 2025

KowalskiThomas mentioned this pull request Dec 25, 2025

fix(profiling): workaround for on-CPU Task race condition #15750

Closed

KowalskiThomas changed the title ~~fix(profiling): workaround for on-CPU madness~~ fix(profiling): workaround on-CPU Task race condition Dec 26, 2025

KowalskiThomas marked this pull request as ready for review December 26, 2025 10:59

KowalskiThomas requested review from a team as code owners December 26, 2025 10:59

KowalskiThomas requested review from mabdinur and taegyunkim December 26, 2025 10:59

KowalskiThomas added the Profiling Continous Profling label Dec 26, 2025

KowalskiThomas force-pushed the kowalski/fix-profiling-workaround-for-on-cpu-task-race-condition-fix-reboot branch from 687aa2c to d41ce1c Compare December 26, 2025 11:07

r1viollet reviewed Dec 28, 2025

View reviewed changes

ddtrace/internal/datadog/profiling/stack/echion/echion/threads.h Show resolved Hide resolved

r1viollet reviewed Dec 28, 2025

View reviewed changes

ddtrace/internal/datadog/profiling/stack/echion/echion/threads.h Outdated Show resolved Hide resolved

r1viollet reviewed Dec 28, 2025

View reviewed changes

ddtrace/internal/datadog/profiling/stack/echion/echion/threads.h Show resolved Hide resolved

r1viollet approved these changes Dec 31, 2025

View reviewed changes

r1viollet reviewed Dec 31, 2025

View reviewed changes

ddtrace/internal/datadog/profiling/stack/echion/echion/threads.h Show resolved Hide resolved

fix(profiling): improve stacks for on-CPU Tasks

7aa74f5

KowalskiThomas force-pushed the kowalski/fix-profiling-workaround-for-on-cpu-task-race-condition-fix-reboot branch from d41ce1c to 7aa74f5 Compare December 31, 2025 15:41

KowalskiThomas requested a review from christophe-papazian December 31, 2025 15:42

KowalskiThomas enabled auto-merge (squash) December 31, 2025 16:00

mabdinur approved these changes Dec 31, 2025

View reviewed changes

KowalskiThomas merged commit 61b1799 into main Jan 1, 2026
446 checks passed

KowalskiThomas deleted the kowalski/fix-profiling-workaround-for-on-cpu-task-race-condition-fix-reboot branch January 1, 2026 01:47

KowalskiThomas added the backport 4.1 label Jan 6, 2026

dd-octo-sts bot mentioned this pull request Jan 6, 2026

fix(profiling): workaround on-CPU Task race condition [backport 4.1] #15854

Merged

Conversation

KowalskiThomas commented Dec 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

What is this about?

Why do we need it?

How does it work?

What does this cost us?

Uh oh!

cit-pr-commenter bot commented Dec 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codeowners resolved as

Uh oh!

pr-commenter bot commented Dec 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Performance SLOs

✅ add_aspect

✅ add_inplace_aspect

✅ add_inplace_noaspect

✅ add_noaspect

✅ bytearray_aspect

✅ bytearray_extend_aspect

✅ bytearray_extend_noaspect

✅ bytearray_noaspect

✅ bytes_aspect

✅ bytes_noaspect

✅ bytesio_aspect

✅ bytesio_noaspect

✅ capitalize_aspect

✅ capitalize_noaspect

✅ casefold_aspect

✅ casefold_noaspect

✅ decode_aspect

✅ decode_noaspect

✅ encode_aspect

✅ encode_noaspect

✅ format_aspect

✅ format_map_aspect

✅ format_map_noaspect

✅ format_noaspect

✅ index_aspect

✅ index_noaspect

✅ join_aspect

✅ join_noaspect

✅ ljust_aspect

✅ ljust_noaspect

✅ lower_aspect

✅ lower_noaspect

✅ lstrip_aspect

✅ lstrip_noaspect

✅ modulo_aspect

✅ modulo_aspect_for_bytearray_bytearray

✅ modulo_aspect_for_bytes

✅ modulo_aspect_for_bytes_bytearray

✅ modulo_noaspect

✅ replace_aspect

✅ replace_noaspect

✅ repr_aspect

✅ repr_noaspect

✅ rstrip_aspect

✅ rstrip_noaspect

✅ slice_aspect

✅ slice_noaspect

✅ stringio_aspect

✅ stringio_noaspect

✅ strip_aspect

✅ strip_noaspect

✅ swapcase_aspect

✅ swapcase_noaspect

✅ title_aspect

✅ title_noaspect

✅ translate_aspect

✅ translate_noaspect

✅ upper_aspect

✅ upper_noaspect

✅ ospathbasename_aspect

✅ ospathbasename_noaspect

✅ ospathjoin_aspect

✅ ospathjoin_noaspect

✅ ospathnormcase_aspect

KowalskiThomas commented Dec 24, 2025 •

edited

Loading

cit-pr-commenter bot commented Dec 24, 2025 •

edited

Loading

pr-commenter bot commented Dec 24, 2025 •

edited

Loading