fix(deno): Enable sessions for HTTP requests

[AG0708]

Deno's node:http server integration disabled release-health sessions even
though the shared HTTP instrumentation enables them by default. Keeping the
shared default aligns Deno with the other server runtimes and restores session
aggregates for incoming requests when a release is configured.

Root cause

The Deno integration passed sessions: false when it subscribed to shared HTTP
server instrumentation. There is no Deno-specific duplicate instrumentation
that requires that override.

• If you've added code that should be tested, please add tests.
• Ensure your code lints and the test suite passes (yarn lint) & (yarn test).
• Link an issue if there is one related to your pull request.

Fixes #22888

[JPeer264]

Hey @AG0708 thanks for your contribution. May I ask if there is an existing issue for this?

But I see that the JSDoc actually says that the default is true.

[AG0708]

Yes—this addresses #22888, which reports that the Deno HTTP integration hard-codes sessions: false despite the shared instrumentation default. The PR body also includes Fixes #22888.

[AG0708]

I rebased this branch onto current develop (71f66dc4), which includes #23391, the upstream pin for the LangChain ESM export failure seen in all five red Node integration jobs. Those failures were in the untouched tracing/langchain/v1 suite; the Deno-focused package tests, transpile, type builds, lint, and formatting had passed before the rebase. The refreshed CI run should now exercise this patch with that upstream dependency fix included.

[github-actions]

👋 @mydea, @JPeer264 — Please review this PR when you get a chance!

[isaacs]

This is the simple targeted fix that makes sessions: true the default. However, it also makes it no longer configurable, which isn't great. What we need to do is extend the options object type and forward them all to the upstream method, so that defaults are aligned with the other HTTP instrumentations.

Pushed a fixup commit which should address this. Waiting on CI.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit ded3cdd. Configure here.}

[isaacs]

@RulaKhaled Since I see you're working on fixing up and organizing the HTTP instrumentation options, could you take a look at this? I've modified this PR a bit too much to be trusted to do the review, I'm afraid 😅

It might be a good idea to rebase onto #23443 or #23396, what do you think?

[RulaKhaled]

@RulaKhaled Since I see you're working on fixing up and organizing the HTTP instrumentation options, could you take a look at this? I've modified this PR a bit too much to be trusted to do the review, I'm afraid 😅

It might be a good idea to rebase onto #23443 or #23396, what do you think?

Happy to review this!

tbh I wouldn’t rebase this onto #23443 / #23396 🤔 they are Node httpIntegration cleanup and don’t touch Deno, so there’s no overlap or conflict. I recommend we land it on develop as is, the Deno option names (onIncomingSpanCreated vs onSpanCreated) can stay for now and we can rename them in a small follow up later as it's a breaking API change that doesn’t need to block this PR (i can create a ticket for this), is this ok?

[RulaKhaled]

Are there any plans to backport this to v10? Asking because it changes how much I'd want this PR to do, though Deno has diverged a fair bit since #22790 :sadge: so it'd be a manual port either way.

Two suggestions:

• Keep this PR small: just the sessions fix, drop sessions: false and add sessions / sessionFlushingDelayMS to DenoHttpIntegrationOptions, forwarded explicitly like the other options. Backportable, and the full Node alignment lands as a follow up.
• Go all the way here: clean up the Deno options to match the Node changes.. drop the onIncoming* aliases and standardize on core's names (v11 only).

Either works, but now extends HttpInstrumentationOptions plus the spread makes core's onSpanCreated a public option, and then onSpanCreated: options.onIncomingSpanCreated silently overwrites it with undefined. If we do want to keep the spread, options.onIncomingSpanCreated ?? options.onSpanCreated (same for onSpanEnd and i think
tracePropagation ?? propagateTrace) would cover it.

What do you think?

[isaacs]

I'd suggest that we not backport to v10, and instead go all the way with making Deno match Node, Bun, and the rest, as much as possible.

• What's in v10 isn't raising any complains, and so the benefit seems pretty low.
• Moving into v11, we should endeavor to keep things as consistent as possible, for our own maintenance ease as much as for user benefit.

Maybe the thing to do is bite the bullet and remove the deno-specific HTTP instrumentation options entirely, and just use the same options as everywhere else, so we just need to provide the errorMonitor and leave the rest untouched. That's a bigger change (and kind of last minute since v11 is now in alpha), but maybe this major is the time to do it.

In either event, I think the thing to do is to clean up the issue you raise here about the onSpanCreated being made public but then silently clobbered, and have a second PR to make it identical to the interface node and others are using.