-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
feat(ui): added notification rule & checks last run status & error #16338
Conversation
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.
the go part LGTM
@@ -182,6 +182,18 @@ export const saveCheckFromTimeMachine = () => async ( | |||
} | |||
} | |||
|
|||
export const updateCheck = (check: Partial<Check>) => async ( |
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.
this was previously removed and caused a breaking change. It has been added back here with the intention of refactoring this implementation with a different ticket
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.
does this still cause a breaking change? can you link the relevant tickets please?
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.
Yes, when I had originally submitted the comment I hadn't had the chance to write up the issue. Here's the breaking change PR:
#16333
but it seems like the changes made to updateCheck weren’t updated here:
https://github.com/influxdata/influxdb/blob/master/ui/src/alerting/components/CheckCard.tsx#L17
and here's the issue that is intended on resolving it :
<>{relativeTimestampFormatter(check.updatedAt, 'Last updated ')}</>, | ||
<LastRunTaskStatus | ||
key={2} |
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.
added the key
here to resolve linter errors
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.
is this a react warning or a lint error? if react is generating a warning then that's the issue we should address. if lint is mistakenly saying we need a key, we should comment an override here, because it's adding meaning to the code to get around a tool issue. do you understand the difference? a real react warning about a list item not having a key is something we should fix, a mistaken lint error trying to head off that warning is something we should comment about, but not change our code to make go away.
if it's an actual react warning, we should give this a more unique name, if possible. react says to only use the item's list index as a last resort
When you don’t have stable IDs for rendered items, you may use the item index as a key as a last resort:
We don’t recommend using indexes for keys if the order of items may change. This can negatively impact performance and may cause issues with component state.
https://reactjs.org/docs/lists-and-keys.html#keys
same comment and any changes that need to happen apply to RuleCard
's key
change
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.
It was a lint error - i imagine stemming from the way clockface
handles metaData being passed dom nodes
<>{relativeTimestampFormatter(rule.updatedAt, 'Last updated ')}</>, | ||
<LastRunTaskStatus | ||
key={2} |
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.
added key
prop here to resolve linter errors
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.
Some comments that appear to be too late.
@@ -1130,7 +1140,9 @@ func TestService_handleUpdateCheck(t *testing.T) { | |||
"statusMessageTemplate": "", | |||
"tags": null, | |||
"type": "deadman", | |||
"labels": [] | |||
"labels": [], |
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 like there's some spacing issue here?
@@ -147,7 +147,9 @@ func Test_newNotificationRuleResponses(t *testing.T) { | |||
], | |||
"type": "slack", | |||
"updatedAt": "0001-01-01T00:00:00Z", | |||
"status": "active" | |||
"status": "active", | |||
"latestCompleted": "0001-01-01T00:00:00Z", |
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.
spacing?
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.
@hoorayimhelping go won't allow for weird formatting. This may look strange but it's kosher in the actual files
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 know gfmt controls spacing, but those things can get weird sometimes, it's always good to confirm and not just trust the machines
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.
for sure. It's all good
"updatedAt": "0001-01-01T00:00:00Z" | ||
"updatedAt": "0001-01-01T00:00:00Z", | ||
"latestCompleted": "0001-01-01T00:00:00Z", | ||
"latestScheduled": "0001-01-01T00:00:00Z" |
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.
spacing?
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.
same as above
@@ -182,6 +182,18 @@ export const saveCheckFromTimeMachine = () => async ( | |||
} | |||
} | |||
|
|||
export const updateCheck = (check: Partial<Check>) => async ( |
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.
does this still cause a breaking change? can you link the relevant tickets please?
<>{relativeTimestampFormatter(check.updatedAt, 'Last updated ')}</>, | ||
<LastRunTaskStatus | ||
key={2} |
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.
is this a react warning or a lint error? if react is generating a warning then that's the issue we should address. if lint is mistakenly saying we need a key, we should comment an override here, because it's adding meaning to the code to get around a tool issue. do you understand the difference? a real react warning about a list item not having a key is something we should fix, a mistaken lint error trying to head off that warning is something we should comment about, but not change our code to make go away.
if it's an actual react warning, we should give this a more unique name, if possible. react says to only use the item's list index as a last resort
When you don’t have stable IDs for rendered items, you may use the item index as a key as a last resort:
We don’t recommend using indexes for keys if the order of items may change. This can negatively impact performance and may cause issues with component state.
https://reactjs.org/docs/lists-and-keys.html#keys
same comment and any changes that need to happen apply to RuleCard
's key
change
} from '@influxdata/clockface' | ||
|
||
// Styles | ||
import './LastRunTaskStatus.scss' |
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.
is this where we want to import this? or should it be imported in in chronograf.scss ?
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.
@hoorayimhelping this was input by @alexpaxton. I'm not entirely sure on best practices but if it's the case that it should be input into the chronograf file I can go ahead and do that
const triggerRef = useRef<HTMLDivElement>(null) | ||
const [highlight, setHighlight] = useState<boolean>(false) | ||
|
||
let color = ComponentColor.Success |
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.
are there implications to setting the default state to success
? if a task run fails and we don't know about it, and we set the status to success, there might be a nonzero impact on the user? what kind of thought have we put into that?
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.
If a task run fails and we don't know about it, that's a failure on the API
let icon = IconFont.Checkmark | ||
let text = 'Task ran successfully!' | ||
|
||
if (lastRunStatus === 'failed' || lastRunError !== undefined) { |
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.
lastRunError !== undefined
is this this check we want here (rather than a more greedy falsy check)? lastRunError = false | null | '' | {}
will pass this check and make the app enter an error state. is that desirable?
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.
That's a great point and definitely something to consider. My thinking here was that since the lastRunError
is an optional parameter (it can be undefined), and since the lastRunError
should be a string if it is defined, the check for explicitly not undefined (meaning a string should exist) should be sufficient. Anything besides a string should trigger an error for us since our API would be behaving unexpectedly if it did return a more generally false check (like false
null
). In this case, an empty string being passed in would be more indicative of improper error handling, but not a reason to prevent the functionality
…16338) feat(ui): added last run status checks for notification rules and check rules, readded updateCheck to fix linter and functionality issues with program and added tests to ensure check creation and update stability
Closes #15838
Solution
Added lastrunstatus check and error handling for notification rules and check rules