Providing an internal module's APIs as non-configurable, non-writable properties

[gabrielschulhof]

Given problems like DataDog/dd-trace-js#2984 (comment), would it make sense to expose the original implementation of Node.js' APIs as non-configurable, non-writable aliases on its various objects? Like,

const dns = require('node:dns');
const originalLookupImplementation = dns._original.lookup; // where dns._original.lookup is just a reference to dns.lookup as defined internally

[bnoordhuis]

Seems like a self-inflicted wound by datadog's agent?

[gabrielschulhof]

StatsD is actually provided by hot-shots, which, AFAICT is independent of Datadog. That's probably why it's unaware of Datadog's wrapping of the dns.lookup() function. The upshot though is that it sends a lot of superfluous spans datadog's way when DNS integration is on, which then distort the resulting traces.

We can solve this problem without the idea I float here, but then each application would have to solve this problem in two steps, where it first captures dns.lookup() before telling Datadog to wrap it, and then passing the captured implementation to hot-shots. The availability of the original implementation would obviate the need for the capture, and would concentrate the solution into a single location in the application code. I guess it would be a bit like primordials, but available to userland.

[bnoordhuis]

That doesn't make it less self-inflicted. It's up to the APM vendor to handle that.

If node added such "primordials", I'm sure vendors will come asking how to instrument them. I've been one, I'm familiar with the mindset.