chore(debugging): guard against race on emitting status

[P403n1x87]

We guard the probe registry against potential race conditions when setting the EMITTING status. This can happen if a probe that has been instrumented is being deleted, but the instrumentation is triggered in a user thread at around the same time the RC client relies the configuration payload. In this case we simply log the event and do nothing.

The better solution would be to lock the registry access, since the handling of the EMITTING status exposes the registry to concurrent access. However, we opted for not introducing a lock to avoid adding blocking in-line on user code.

Checklist

• PR author has checked that all the criteria below are met
• The PR description includes an overview of the change
• The PR description articulates the motivation for the change
• The change includes tests OR the PR description describes a testing strategy
• The PR description notes risks associated with the change, if any
• Newly-added code is easy to change
• The change follows the library release note guidelines
• The change includes or references documentation updates if necessary
• Backport labels are set (if applicable)

Reviewer Checklist

• Reviewer has checked that all the criteria below are met
• Title is accurate
• All changes are related to the pull request's stated goal
• Avoids breaking API changes
• Testing strategy adequately addresses listed risks
• Newly-added code is easy to change
• Release note makes sense to a user of the library
• If necessary, author has acknowledged and discussed the performance implications of this PR as reported in the benchmarks PR comment
• Backport labels are set in a manner that is consistent with the release branch maintenance policy

[github-actions]

CODEOWNERS have been resolved as:

ddtrace/debugging/_probe/registry.py                                    @DataDog/debugger-python

[github-actions]

Bootstrap import analysis

Comparison of import times between this PR and main.

Summary

The average import time in this PR is: 236 ± 3 ms.

The average import time in main is: 242 ± 3 ms.

The import time difference between this PR and main is: -5.4 ± 0.1 ms.

Import time breakdown

The following import paths have shrunk:

ddtrace.auto 2.491 ms (1.05%)

ddtrace.bootstrap.sitecustomize 1.608 ms (0.68%)

ddtrace.bootstrap.preload 1.569 ms (0.66%)

ddtrace.internal.products 1.569 ms (0.66%)

ddtrace.internal.remoteconfig.client 0.706 ms (0.30%)

ddtrace.internal.symbol_db.remoteconfig 0.121 ms (0.05%)

multiprocessing 0.121 ms (0.05%)

multiprocessing.context 0.121 ms (0.05%)

multiprocessing.reduction 0.121 ms (0.05%)

pickle 0.121 ms (0.05%)

_compat_pickle 0.121 ms (0.05%)

ddtrace._trace.trace_handlers 0.039 ms (0.02%)

ddtrace._trace.utils_botocore.span_tags 0.039 ms (0.02%)

ddtrace._trace.utils_botocore.aws_payload_tagging 0.039 ms (0.02%)

ddtrace.vendor.jsonpath_ng 0.039 ms (0.02%)

ddtrace.vendor.jsonpath_ng.parser 0.039 ms (0.02%)

ddtrace.vendor.ply.yacc 0.039 ms (0.02%)

ddtrace 0.883 ms (0.37%)

ddtrace._logger 0.047 ms (0.02%)

ddtrace.settings._core 0.047 ms (0.02%)

ddtrace.settings 0.047 ms (0.02%)

ddtrace.settings._config 0.047 ms (0.02%)

ddtrace.settings._telemetry 0.047 ms (0.02%)

ddtrace.internal.telemetry 0.047 ms (0.02%)

ddtrace.internal.telemetry.writer 0.047 ms (0.02%)

ddtrace.internal.telemetry.data 0.047 ms (0.02%)

ddtrace.internal.packages 0.047 ms (0.02%)

_sysconfigdata__linux_x86_64-linux-gnu 0.047 ms (0.02%)

ddtrace.internal._file_queue 0.035 ms (0.01%)

secrets 0.035 ms (0.01%)

hmac 0.035 ms (0.01%)

_hashlib 0.035 ms (0.01%)

[pr-commenter]

Benchmarks

Benchmark execution time: 2025-03-24 22:03:49

Comparing candidate commit 1b2b72d in PR branch chore/debugger-emitting-race with baseline commit 08ee25b in branch main.

Found 0 performance improvements and 0 performance regressions! Performance is the same for 498 metrics, 2 unstable metrics.