Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Allow filtering HTTP auto instrumentation request errors

See original GitHub issue

Feature Request

Is your feature request related to a problem?

We’re using HTTP auto instrumentation in our applications and we would like to be able to change some “false” errors in order to get a better visualization on the UI, for example: A request to AWS/S3 to get a file which returns a 404, most of the time this is used by us to check if the file exists (it’s not an error per se, in this context).

I think this subject is controversial, but I would like to know the contributors opinion on that. My company has just started to instrument applications with distributed tracing so it would be nice to know if others had problems like this as well in their instrumentation, opinions on the matter and any workarounds.

Describe the solution you’d like:

Maybe the HTTP auto instrumentation initialization could have a parameter just like the Filter one, which will be called to decide whether a finished HTTP activity should be tagged with Status.Ok or Status.Error.

Which alternative solutions or features have you considered?

We tried to .SetStatus(Status.Ok) using the Enrich feature - It didn’t work though. As a workaround we enriched the activity with an error=false attribute (on our specific tracing backend this worked, but it seems to be a unreliable workaround).