Custom config for express are ignored when plugins is enabled

[Axxiss]

Describe the bug

When tracer is configured with plugins: true then blocklist doesn't work when instrumenting the express plugin (don't know if it happen for other plugins). Request are not dropped by dd-trace-js.

import tracer from 'dd-trace';

tracer.init({
  plugins: true,
});

tracer.use('express', { blocklist: ['/status'] });
export default tracer;

If we set plugins: false then request are dropped by dd-trace-js

Related https://github.com/DataDog/dd-trace-js/issues/978

Environment

• Operation system: reproduced in both both MacOS and Linux
• Node version: v14.14.0
• Tracer version: 1.0.0

[parialegend]

Hi @Axxiss Were you able to resolve this by any means?

[rochdev]

This is actually a bug with how the config is loaded for Web frameworks which may be overridden by the configuration from the http plugin. You can work around this issue with 2 steps:

1. Make sure that tracer initialization happens before any other module is imported. The easiest way to do this is with NODE_OPTIONS='-r dd-trace/init' in the startup command, or if you need programmatic configuration, with your own file so for example NODE_OPTIONS='-r /datadog.js' which would contain a snippet similar to the above. It can also be done programmatically but it's a bit more complicated especially if using a bundler to make sure the tracer is initialized first. If you are 100% sure that this is already the case, disregard this step.
2. Instead of configuring the blocklist on the express plugin, configuring it on the http plugin instead would generally solve this issue. So for example: tracer.use('http', { blocklist: ['/status'] }).

Unfortunately it's not a bug we can easily fix with the way these plugins interact today, but we're reworking the plugin system in a way that will naturally solve this eventually.

[Axxiss]

For the record, I went with the second option. Configuring the block in the HTTP layer did the trick.

[shantanu1227]

This is actually a bug with how the config is loaded for Web frameworks which may be overridden by the configuration from the http plugin. You can work around this issue with 2 steps:

1. Make sure that tracer initialization happens before any other module is imported. The easiest way to do this is with NODE_OPTIONS='-r dd-trace/init' in the startup command, or if you need programmatic configuration, with your own file so for example NODE_OPTIONS='-r /datadog.js' which would contain a snippet similar to the above. It can also be done programmatically but it's a bit more complicated especially if using a bundler to make sure the tracer is initialized first. If you are 100% sure that this is already the case, disregard this step.
2. Instead of configuring the blocklist on the express plugin, configuring it on the http plugin instead would generally solve this issue. So for example: tracer.use('http', { blocklist: ['/status'] }).

Unfortunately it's not a bug we can easily fix with the way these plugins interact today, but we're reworking the plugin system in a way that will naturally solve this eventually.

The second method was working in version 1.1.1, but after migrating to 2.0.1 this stopped working.

[rochdev]

@shantanu1227 We've slightly changed how the tracer is loaded which could cause that workaround to stop working in some cases. However, assuming that the first point has been addressed and if you are 100% sure that dd-trace is initialized before anything else is imported, then tracer.use('express', { ... }) should work.

[shantanu1227]

@shantanu1227 We've slightly changed how the tracer is loaded which could cause that workaround to stop working in some cases. However, assuming that the first point has been addressed and if you are 100% sure that dd-trace is initialized before anything else is imported, then tracer.use('express', { ... }) should work.

@rochdev I tried using this tracer.use('express', { blocklist: ['/api/health'] }) as well, but no luck. I get manual { drop 1 } as an extra tag in datadog, which I don't see in other request paths.

[rochdev]

Sounds like it could be a bug. The manual.drop tag should never appear in the UI since adding this tag should result in the trace being dropped. I'll have to look into that.

[billo-zymantas]

Any updates on this ? As we are experiencing this issue with none of previous workarounds working

[jjsimps]

I am also experiencing this issue -- and the workaround are not working.

[rochdev]

We're in the process of rewriting the part of the tracer that handles this since it has too many issues. This should happen fairly soon after which this should work properly again.

[andrew-kolesnikov]

Was there any progress on this issue?

[rochdev]

@andrew-kolesnikov Do you still have the issue with the latest version?

[khanayan123]

Going to close this issue due to inactivity, please feel free to open the issue again if you are still having problems