fix(openai): tracing occurs in correct async context

[sabrenner]

What does this PR do?

Ensures tracing and parentage is tracked appropriately across different async contexts by migrating the OpenAI plugin to use tracing channel/appropriate internal APIs.

Motivation

Previously, something like:

await tracer.trace('outer', async () => {
  await openai.chat.completions.create(...)
  tracer.trace('child', () => {})
})

Would have child as a child span of the openai.request span, and not the outer span. By migrating to tracing channel and using the internal APIs for later versions, this parentage/context is maintained. This is validated with a regression test, for both streamed and non-streamed cases.

Plugin Checklist

• Unit tests.
• TypeScript definitions.
• TypeScript tests.
• API documentation.
• CircleCI jobs/workflows.
• Plugin is exported.

[github-actions]

Overall package size

Self size: 6.95 MB
Deduped: 58.17 MB
No deduping: 58.45 MB

Dependency sizes

| name | version | self size | total size | |------|---------|-----------|------------| | @datadog/native-appsec | 8.0.1 | 15.59 MB | 15.6 MB | | @datadog/native-iast-taint-tracking | 3.1.0 | 12.27 MB | 12.28 MB | | @datadog/pprof | 5.3.0 | 9.85 MB | 10.22 MB | | protobufjs | 7.2.5 | 2.77 MB | 5.16 MB | | @datadog/native-iast-rewriter | 2.4.1 | 2.14 MB | 2.23 MB | | @opentelemetry/core | 1.14.0 | 872.87 kB | 1.47 MB | | @datadog/native-metrics | 2.0.0 | 898.77 kB | 1.3 MB | | @opentelemetry/api | 1.8.0 | 1.21 MB | 1.21 MB | | import-in-the-middle | 1.8.1 | 71.67 kB | 785.15 kB | | msgpack-lite | 0.1.26 | 201.16 kB | 281.59 kB | | opentracing | 0.14.7 | 194.81 kB | 194.81 kB | | pprof-format | 2.1.0 | 111.69 kB | 111.69 kB | | @datadog/sketches-js | 2.1.0 | 109.9 kB | 109.9 kB | | semver | 7.6.3 | 95.82 kB | 95.82 kB | | lodash.sortby | 4.7.0 | 75.76 kB | 75.76 kB | | lru-cache | 7.14.0 | 74.95 kB | 74.95 kB | | ignore | 5.3.1 | 51.46 kB | 51.46 kB | | int64-buffer | 0.1.10 | 49.18 kB | 49.18 kB | | shell-quote | 1.8.1 | 44.96 kB | 44.96 kB | | istanbul-lib-coverage | 3.2.0 | 29.34 kB | 29.34 kB | | tlhunter-sorted-set | 0.1.0 | 24.94 kB | 24.94 kB | | limiter | 1.1.5 | 23.17 kB | 23.17 kB | | dc-polyfill | 0.1.4 | 23.1 kB | 23.1 kB | | retry | 0.13.1 | 18.85 kB | 18.85 kB | | jest-docblock | 29.7.0 | 8.99 kB | 12.76 kB | | crypto-randomuuid | 1.0.0 | 11.18 kB | 11.18 kB | | path-to-regexp | 0.1.7 | 6.78 kB | 6.78 kB | | koalas | 1.0.2 | 6.47 kB | 6.47 kB | | module-details-from-path | 1.0.3 | 4.47 kB | 4.47 kB |

_{🤖 This report was automatically generated by heaviest-objects-in-the-universe}

[pr-commenter]

Benchmarks

Benchmark execution time: 2024-08-12 19:17:43

Comparing candidate commit bd2b48f in PR branch sabrenner/openai-tracing-fix with baseline commit ed9b0b3 in branch master.

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

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 69.19%. Comparing base (f82c6d5) to head (04adfbb).
Report is 7 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4583      +/-   ##
==========================================
+ Coverage   63.02%   69.19%   +6.16%     
==========================================
  Files         254        1     -253     
  Lines       11095      198   -10897     
  Branches       33       33              
==========================================
- Hits         6993      137    -6856     
+ Misses       4102       61    -4041     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[rochdev]

By properly wrapping the traced functions in a shared async resource, this parentage/context is maintained.

Using AsyncResource alters the async context for all code in the process. Could we instead switch the openai integration over to TracingChannel to avoid unintended side-effects of altering the async stack?

[sabrenner]

Could we instead switch the openai integration over to TracingChannel to avoid unintended side-effects of altering the async stack?

For sure! I think this should be pretty doable for the patching of older versions of OpenAI (<=3), but I'm wondering if it would be a bit harder for the newer patching because of how we currently trace streamed responses (based on my understanding of TracingChannel). Happy to chat offline with more details, but if we have an instance of a more complex migration of an integration to TracingChannel, that might help me out.

[rochdev]

if we have an instance of a more complex migration of an integration to TracingChannel, that might help me out.

There are grpc and http that both use the lower-level API since they are also stream-based.

[sabrenner]

@rochdev thanks! I think I've implemented this correctly, the test I added is still passing for both streamed and non-streamed cases, and i think it's following established patterns for other TracingChannel migrations for other plugins.