-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[ResponseOps][Rules] Adding rule.url variable #145035
[ResponseOps][Rules] Adding rule.url variable #145035
Conversation
Pinging @elastic/response-ops (Team:ResponseOps) |
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.
LGTM; made a comment about a comment and suggestion to add a debug log ...
`); | ||
}); | ||
|
||
it('does not populate the rule.url when the alert id is set to undefined', 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.
it('does not populate the rule.url when the alert id is set to undefined', async () => { | |
it('does not populate the rule.url when the rule id is set to undefined', async () => { |
Just to make it a little clearer :-)
`); | ||
}); | ||
|
||
it('does not populate the rule.url when the alert id is a number', 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.
I'm curious why we're even handling this case. Not something I think we usually test, so curious ...
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.
Yeah the reason I thought this was worth covering is because the way we've typed the task manager params is Record<string, any>
. So when we destructure taskInstance.params
it's showing alertId: ruleId
as type any
. So I figured it's probably worth skipping the rule building if the type is anything but a string 🤷♂️
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.
Ah! Looking closer, I missed the buildRuleUrl()
method is referencing this.taskInstance.params.alertId
- I missed that before, and that does seem a little brittle. Looking at it's call site, it looks like you could instead pass ruleId
as a parameter.
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.
Yeah I can pass it as a parameter, but just to make sure I'm understanding, that doesn't address it being typed as any
right? I still need to ensure it is a string.
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.
Ah, good catch - ya, that variable is extracted from the same place 🤦🏻♂️ .
However, I noticed a this.rule
available, so I think you can leave it parameterless and change
this.taskInstance.params.alertId
-> this.rule.id
|
||
return ruleUrl.toString(); | ||
} catch (error) { | ||
return; |
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.
feels worthy of a log.debug()
, just in case this case gets caught, but we're confused why the url didn't 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.
LGTM; made a comment about a comment and suggestion to add a debug log ...
Also a comment about using the getRuleDetailsRoute()
somewhere it's not currently being used. I'm sure this would end up needing to be fixed when this code gets more plugin-specific, so doesn't seem like a biggie.
@@ -886,7 +887,7 @@ export const RulesList = ({ | |||
onPage={setPage} | |||
onRuleChanged={() => refreshRules()} | |||
onRuleClick={(rule) => { | |||
const detailsRoute = ruleDetailsRoute ? ruleDetailsRoute : routeToRuleDetails; | |||
const detailsRoute = ruleDetailsRoute ? ruleDetailsRoute : commonRuleDetailsRoute; | |||
history.push(detailsRoute.replace(`:ruleId`, rule.id)); |
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 there some reason we don't use getRuleDetailsRoute(rule.id)
here, as was done in rule_details.tsx
above?
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 ruleDetailsRoute
is passed in as a prop to this component and it wasn't clear to me what the value would be. So I don't think we can rely on it equaling commonRuleDetailsRoute
aka '/rule/:ruleId'
. So if we called getRuleDetailsRoute
here it could change the initial part of the path (/rule
may not exist in the ruleDetailsRoute
passed in as a prop).
Another option is that we change getRuleDetailsRoute
to take the path portion but that's pretty close to just calling .replace
directly 🤷♂️
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.
thx
Feels like this is going to change with the rule-type-specific route stuff in a subsequent PR anyway, so feels like we should just leave it alone for now :-)
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.
ok sounds good!
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.
AO changes LGTM.
This comment was marked as resolved.
This comment was marked as resolved.
Following up as we've continued this discussion offline. Christos and I tried to reproduce this and we weren't able to. Ying also checked on the cloud deployment and wasn't seeing it there. Seems like this is a race condition somewhere. |
💚 Build Succeeded
Metrics [docs]Module Count
Public APIs missing comments
Async chunks
Page load bundle
Unknown metric groupsAPI count
async chunk count
ESLint disabled in files
ESLint disabled line counts
Total ESLint disabled count
History
To update your PR or re-run it, just comment with: |
This PR adds a new actions variable for linking back the stack management rule page. In a future PR we will require the rule type to specify the plugin's path when registering the rule type that way we can link back to the specific plugin that created the rule.
Issue: #145132
Mustache variable
Constructed URL