Url tag value is maintained throughout exceptions

[Meilu]

Currently testing some exceptions and noticed that the Url tag keeps the same value as the first exception when viewed in sentry dashboard. Any consecutive exceptions will always have the same url tag value as the initial one.
Have tried overriding it when creating an sentry event but that did not work.
I can get it to work by initialising a new ravenclient on every exception but that seems a bit too much i think.

[lwhuybrechts]

It appears that the headers from the first exception are also maintained and logged with any consecutive exceptions (even when there are exceptions from different requests).
@asbjornu Are we supposed to create a new RavenClient for every exception? Is there any way we can fix this on our side? :)

[asbjornu]

@Meilu @lwhuybrechts, This sounds like a bug introduced in v2.0. If you're able to pinpoint what change might have introduced the problem, I'd highly appreciate it. You're not supposed to create a new instance of RavenClient for every exception. 😃

[lwhuybrechts]

@asbjornu Hey Asbjørn, I'm afraid we've only just started implementing Sentry (coming from Elmah) in our WebAPI, so it's really hard to say what might have changed since v2.0. Overall it has been hard implementing raven-csharp without up-to-date documentation ;)

We have been trying to find the cause of this problem by inspecting the source and trying to debug, but no success so far. Is there a chance someone can help us out? Any help is greatly appreciated! Thanks :)

[Meilu]

@asbjornu i may have found the bug, in the GetHttpContext() method there is a check if the HttpContext already exists or not. If it exists it does not rebuild the context but used the same static httpcontext again that was created on the first request. Because the httpcontext is static even creating a new ravenclient on every request will not solve our issue.

[Meilu]

created a pull request but noticed its not optimal and needs some work, ill try to finish a pull request today

[asbjornu]

@Meilu, @lwhuybrechts #116 has now been merged and is included in the latest prerelease package on NuGet. Please try it out and report back if it helps remedy the problem or not.

[Meilu]

@asbjornu thanks! We have installed the prerelease version and will set it live tommorow. So far it looks like this has fixed it. We'll let you know if anything is wrong.

[asbjornu]

@Meilu I'm glad to hear that! Now, do you have any idea on how we can test this?

[Meilu]

@asbjornu sure, if you mean if it works and if it fixes our bug, in our case since we are using a webapi we simply test multiple calls that crash with different users. We check the headers and the url value in sentry and see if the values are the unique for every user (access tokens, language etc). Performance wise there should also be no noticeable delays since it should not try to get the latest httpcontextproperty through reflection but reuse the one it tried to fetch from the first call (if any).

Not tested:

• applications that do not use an httpcontext. For these applications it should only check if the httpcontext exists just once and not crash for any calls after that. Also no performance decreases or memory increases should occur.

[asbjornu]

@Meilu I was thinking about an automated NUnit test. Applications that don't use HttpContext should not care; that's why I wrote the reflection-based prodding for System.Web.HttpContext.Current in the first place.

[asbjornu]

@Meilu: Does this still work as intended? If you could provide a unit test for this, that would be highly appreciated!