-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Send 'error' severity by default & document how to set it #55
Conversation
515d881
to
56c5939
Compare
/// Error severity. | ||
/// </summary> | ||
[JsonProperty("severity")] | ||
string Severity { get; set; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Plz add public
modifier here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
5dc7a3a
to
bc33fa5
Compare
This is an upcoming feature.
Fixed build, added description to README. PTAL |
👍 As stated in https://airbrake.io/docs/airbrake-faq/what-is-severity/ Airbrake supports well-defined list of severities (i.e. debug, info, notice, etc.). It makes sense to implement it as an You can define it in the next way: public enum Severity
{
Debug,
Info,
// etc...
} I am not sure also whether it should be a part of |
👍 to enum
Anything should be able to set severity. It's a basic feature and every app has its own understand of what's severe and what is not. |
Yep, that's why I propose to set it not via HttpContext but using some other mechanism. One solution is to pass it via parameter to NotifyAsync(Exception exception, IHttpContext context = null, Severity = Severity.Error) If you don't mind, tomorrow we can work together on that part. |
Why would we special case it? Currently, we pass I don't see why Severity deserves special treatment. It's just another parameter in the context payload. |
From what I can see these parameters are HTTP related:
|
I agree with this rationale. I didn't phrase it correctly. It's a place for HTTP params, yes. However, sometimes we need to store extra information and Params is the default place for that. Anything extra should go there. NotifyAsync(Exception exception, IHttpContext context = null, Severity = Severity.Error) ^^ this code looks good, as long as we can support other fields (if we need them in the future). For example: NotifyAsync(Exception exception, IHttpContext context = null, {
Severity = Severity.Error,
OtherThing = Val
}) This API looks acceptable. Would you be able to replace this PR with a different one? It'll take me quite some time to implement it. |
If this is a common place where severity is put (or will be put if this is a new feature) for other notifiers, then we should follow that convention as well. And I don't see any problems here. At the same time, we are not forced to use IHttpContext interface for that. We can use some other, more appropriate and less "semantic breaking" mechanism for passing the value of severity to
Not sure that we can guarantee "as long as we can support other fields" part. I think that we should consider each case individually and make a decision based on the purpose of each particular field. If there will be a lot of such "custom" fields, perhaps we should come with some solution, but it's quite hard to talk about such solution in advance. Let's come back to error severity. As for me, this is a quite "important" field that deserves its own parameter in the |
Severity should be put in Arbitrary params are useful for user filters. Let's say for some reason you want to send a custom environment variable. You define a new filter, read the value, now you need to attach it to the notice object. The params dict is the correct place for that. It's basically a dumpster for everything.
Sounds good.
Thanks! I have no objections. Hit merge as long as you are happy with the code. After that, we will want to make a new minor release. |
This is an upcoming feature.