chore(llmobs): fix flaky writer test

[lievan]

This test has been flaky and relies on the subprocess outputting certain error logs that verify spans are being enqueued to the correct writer

Try to make it less flaky by

1. increasing the likelihood the error log happens by decreasing the writer interval time. i think on exit, periodic should be called anyway, but this shouldn't hurt
2. sleep a bit before exiting
3. flush stderr/stdout manually before exiting

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:

tests/llmobs/test_llmobs_service.py                                     @DataDog/ml-observability

[Yun-Kim]

On second thought - should we consider changing this test to just assert the class/type of LLMObs span writer? Will that be more reliable than asserting error/stdout logs?

[github-actions]

Bootstrap import analysis

Comparison of import times between this PR and base.

Summary

The average import time from this PR is: 278 ± 3 ms.

The average import time from base is: 280 ± 3 ms.

The import time difference between this PR and base is: -1.8 ± 0.1 ms.

Import time breakdown

The following import paths have shrunk:

ddtrace.auto 1.957 ms (0.70%)

ddtrace.bootstrap.sitecustomize 1.283 ms (0.46%)

ddtrace.bootstrap.preload 1.283 ms (0.46%)

ddtrace.internal.remoteconfig.client 0.643 ms (0.23%)

ddtrace 0.674 ms (0.24%)

ddtrace.internal._unpatched 0.031 ms (0.01%)

json 0.031 ms (0.01%)

json.decoder 0.031 ms (0.01%)

re 0.031 ms (0.01%)

enum 0.031 ms (0.01%)

types 0.031 ms (0.01%)

[lievan]

hmm yea @Yun-Kim i also thought of just directly asserting that the endpoint the writer has is what we expect it to be, but looking at the original pr for this test being introduced it relates to "duplicate spans" being enqueued to potentially different writers? #11889

idk if simply asserting on the endpoint for LLMObs._writer would catch that issue, could that be the reason why this test use logs in the first place?

[pr-commenter]

Benchmarks

Benchmark execution time: 2025-07-11 16:35:28

Comparing candidate commit 9ebacc3 in PR branch fix-flaky-test with baseline commit 7a87f98 in branch main.

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

[Yun-Kim]

idk if simply asserting on the endpoint for LLMObs._writer would catch that issue, could that be the reason why this test use logs in the first place?

@lievan let's just change to test on the writer endpoint, since that will still cover the original case of #11889.