Question or Bug?

I use restify and redis to test zipkin-js, script as follow

const restify = require('restify');
const {Tracer, ExplicitContext, ConsoleRecorder, BatchRecorder} = require('zipkin');
const zipkinMiddleware = require('zipkin-instrumentation-restify').restifyMiddleware;
const zipkinClient = require('zipkin-instrumentation-redis');
const Redis = require('redis');

const redisConnectionOptions = {
  host: '192.168.4.114',
  port: 6379
};

const ctxImpl = new ExplicitContext();
const recorder = new ConsoleRecorder();
const tracer = new Tracer({ctxImpl, recorder});

const redis = zipkinClient(tracer, Redis, redisConnectionOptions, "redis");
const app = restify.createServer();

app.use(zipkinMiddleware({
  tracer,
  serviceName: 'service-a'
}));

app.get('/echo/:name', function (req, res, next) {
  const name = req.params.name
  redis.set(name, name, (err, data) => {
    redis.get(name, (err, data) => {
      res.send(req.params)
      return next()
    })
  });
});

app.listen(9999, function () {
  console.log('%s listening at %s', app.name, app.url);
});

I think result is not right

[ppg]

@adriancole thanks for the response. I don’t think we’re in any disagreement, but for your item 2, per the example @feifeiiiiiiiiiii provided, using CLS with scoped doesn’t actually scope it and downstream code won’t be able to ‘see’ it, only synchronous code will ‘see’ it. Its hard (for me) to imagine many uses of express that don’t have some asynchronous behavior in their middleware and endpoints, so out of the box the express middleware isn’t going to work very well for them. The only solution is every single middleware would need to call .scoped, which aside from being tedious, is unrealistic if you don’t own all the middlewares explicitly.

It seems like a better approach for express (and likely restify) would be to add a concept of the context onto either the request, or response.locals; it is after all where express says to put per request scoped objects, which is what the TraceId is. Then when the context, or more appropriately span, is needed you could grab from there and either pass into context/span aware clients, or create child spans to perform work.

[codefromthecrypt]

I think perhaps the interactions around “scoped” need more exploration. I don’t know how scheduling works here. Maybe we can get more specific, like raise a test which has a user-provided code which needs to add to a trace, and show how scoping doesn’t work? It would be faster for me to help as I am not as good in js as others…

One thing I’d like to see is if there’s an instrumentation approach we can use that prevents users from needing to know special knowledge about a library specific request or response scope. Not saying we won’t end up needing that out, just want to see concretely where it ends…

PS I put a few words here and happy to have help elaborating the general problem https://docs.google.com/document/d/16byriP7jCi2xmLf8IveTTy5ttoGFgd9hn8hg_QkfMTU/edit#heading=h.burk117bfcxf