[Alerting] Rule details page should always use resolve API

[ymao1]

With this PR, we updated the rule details page to try to load the rule using the normal GET API and only try using the new resolve API when the GET returns a 404.

@dhurley14 identified a bug with this logic because in the case of an SO ID conflict, the GET API would not return a 404, instead it would just return a SO (possibly not the right one) and the conflict message would never show up.

We should update to always use resolve when loading the rule details page so conflicts can be identified appropriately.

[elasticmachine]

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

[ymao1]

@jportner Does this line up with your understanding as well?

[jportner]

@jportner Does this line up with your understanding as well?

Oh, yes you should just use resolve directly in the case of a deep link.

I noticed in the linked PR you also mentioned:

• Not sure how to recreate a conflict outcome but if you want to see the conflict callout, you could modify x-pack/plugins/triggers_actions_ui/public/application/sections/alert_details/components/alert_details_route.tsx to set the outcome to conflict after the resolve call.

The sharing saved objects dev guide includes a link to a script to generate staging data. However that only works for exportable objects. To simulate a conflict outcome, you can manually manipulate the raw saved object docs in Elasticsearch; feel free to ping me when the time comes and I can help with that.

[chrisronline]

Is this going to affect your telemetry @jportner? This change would mean all page loads for any rule detail page would cause a hit for the .resolve() api in the telemetry data

[jportner]

Is this going to affect your telemetry @jportner? This change would mean all page loads for any rule detail page would cause a hit for the .resolve() api in the telemetry data

Yes, this is expected. Any "deep link" URL should result in a call to resolve(); our usage data tracks how often each outcome is encountered.

When we say that we don't want to over-use the resolve() API, we mean that it should not be used for an object ID that doesn't come from a deep link URL, in general (though there are a few exceptions).

So I think this PR is good to merge 👍

[chrisronline]

Thanks for clarifying @jportner!