-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Monitor Conditions #5048
Monitor Conditions #5048
Conversation
This comment has been minimized.
This comment has been minimized.
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.
Looks very nice. Good job.
The testcases are most appreciated ❤️
I have left a few inline comments below. ^^
// eslint-disable-next-line eqeqeq | ||
return variable == value; |
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.
Why not the following? (also goes for NotEqualsOperator)
Could you add a comment explaining the reasoning ^^
// eslint-disable-next-line eqeqeq | |
return variable == value; | |
return variable === value; |
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.
I initially was going to add an mx_priority
variable to check MX record priorities. Node's DNS module parses MX records and returns priority as a number type.
In this new conditions UI, comparison values are stored as strings. i.e. My condition would be stored in the monitor as mx_priority equals "10"
.
I have a set of numeric operators (less than, greater than, etc) that cast the value to Number internally, but the EqualsOperator is currently used for both strings and numbers. It needs loose equality to handle 10 == "10".
An alternate solution could be to rename this operator to StringEquals (make it strict) and add a new NumberEquals operator (also strict) that casts value internally.
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.
Adding a comment that this is because of sharing between numbers and strings to handle 10 == "10"
is likely fine.
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.
I'm flip-flopping on this.
I can't currently think of a scenario where the loose equality operators wouldn't get the job done, but I think it may be advantageous to start this feature out with strict operators rather than maybe trying to implement them later on and have to worry about backwards compatibility.
So, a monitor type would need to use the default string or number operators, or explicitly use either StringEquals
or NumberEquals
when declaring its supported condition variables.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
Since #5056 was merged, I've fixed, added to, and improved the E2E tests for this PR. I'll go through your remaining comments sometime later today. |
…g and Number operators
I think I've handled all the remaining issues. |
Thanks for the enhancement! 🎉 Note This PR is part of the All changes in this PR are small and uncontroversial ⇒ merging with junior maintainer approval |
i am working on below improvement. as per my research. console.log("sdfwfwkjfhwhfkwefjewf");
console.log(this.conditions);
console.log("sdfwfwkjfhwhfkwefjewf"); this.conditions is no value so it is i think blank then we need to pass some default json or null. |
The migration in this database changes sets a default value of |
i am using mariadb. is there any problem with MySQL? have you written migration for MySQL? |
@vishalsabhaya The migration should be database agnostic. Can you confirm via DBMS the default value of the conditions column in the monitor table? |
Tick the checkbox if you understand [x]:
Description
Hello,
We have a need at work for monitoring values of DNS records. I got (really) bored and decided to do something about it. I understand this is a semi-major feature and may need some changes, or maybe you don't like it all. That's fine.
This PR introduces support for setting up conditions that affect UP/DOWN status on monitors. It pertains to #3919 and eventually, I think, could obviate the need for the keyword type, and maybe the JSON Query type.
It is opt-in per type, and I've only opted-in the DNS type for now. So, this doesn't break existing keyword/JSON query types. It's generic but extendable enough in my opinion that it could allow implementing a wide variety of scenarios without needing further UI changes going forward.
Currently missing the ability to drag conditions around, but that shouldn't be too difficult to shoehorn in eventually.
Screenshots below.
Type of change
Checklist
Screenshots (if any)
Groups: