Fix saving index pattern when there is a conflict

[jen-huang]

Fixes #21932

Changes in #20384 changed error handling to return kfetch's FetchError object. Saving index pattern is dependent on statusCode, which is not a top level property of FetchError. PR updates to look for res.status instead.

[nreese]

The problem is that you are not getting the REST resp from kfetch. kfetch is going to reject the promise with a FetchError

[jen-huang]

FetchError still has res and body properties:
https://github.com/elastic/kibana/blob/master/src/ui/public/kfetch/kfetch.ts#L29

I'll rename these variables so they reflect an instance of FetchError.

[nreese]

This is going to break places that have been updated to handle a FetchError. I would recommend just updating the consumers to directly handle FetchError.

https://github.com/elastic/kibana/blob/master/src/ui/public/error_auto_create_index/error_auto_create_index.js#L32

https://github.com/elastic/kibana/blob/master/src/ui/public/courier/saved_object/saved_object.js#L305

[jen-huang]

@nreese Thanks for those references! I'm concerned about the places that haven't been updated to know about FetchError and are still attempting to read top level statusCode (the only problematic/missing property). Grepping on statusCode shows many results and it's hard to tell if those references are in saved objects context. I'd like to get your assessment on the likelihood of similar breakage in other areas.

I'll update this PR to modify the index pattern client instead in the meantime.

[nreese]

lgtm
code review

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

23:57:29    │ proc  [ftr]        └-> "before all" hook
23:57:29    │ proc  [ftr]        └-> applies the correct CSS classes
23:57:29    │ proc  [ftr]          └-> "before each" hook: global before each
23:57:29    │ proc  [ftr]          │ debg  TestSubjects.find(grokDebugger acePatternInput codeEditorContainer)
23:57:29    │ proc  [ftr]          │ debg  findByCssSelector [data-test-subj~="grokDebugger"] [data-test-subj~="acePatternInput"] [data-test-subj~="codeEditorContainer"]
23:57:29    │ proc  [ftr]          │ debg  TestSubjects.find(grokDebugger acePatternInput codeEditorContainer)
23:57:29    │ proc  [ftr]          │ debg  findByCssSelector [data-test-subj~="grokDebugger"] [data-test-subj~="acePatternInput"] [data-test-subj~="codeEditorContainer"]
23:57:30    │ proc  [ftr]          │ info  Taking screenshot "/var/lib/jenkins/workspace/elastic+kibana+pull-request+multijob-x-pack/kibana/x-pack/test/functional/screenshots/failure/logstash grok debugger app syntax highlighting applies the correct CSS classes.png"
23:57:30    │ proc  [ftr]          │ info  Current URL is: http://localhost:5640/app/kibana#/dev_tools/grokdebugger?_g=()
23:57:30    │ proc  [ftr]          │ info  Saving page source to: /var/lib/jenkins/workspace/elastic+kibana+pull-request+multijob-x-pack/kibana/x-pack/test/functional/failure_debug/html/logstash grok debugger app syntax highlighting applies the correct CSS classes.html
23:57:30    │ proc  [ftr]        └- ✖ fail: "logstash grok debugger app syntax highlighting applies the correct CSS classes"
23:57:30    │ proc  [ftr]        │        [GET http://localhost:9515/session/f6ea74747226692705633433d95ce268/element/0.23236615736280375-35/text] stale element reference: element is not attached to the page document

[jen-huang]

Retest

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

Same failure as above. Passes locally 😞Merging master to see if that helps.

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

Weird ES-related failures. Aborted.

[jen-huang]

Retest

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[jen-huang]

Retest

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[LeeDr]

@jen-huang What will happen now in this same case? What will the user see?

In the issue this PR fixes, it could really be any Kibana user that does something that causes a change to the index pattern while you're trying to format a field or add a scripted field which causes the version conflict.
We don't want this user to clobber the previous version change. I'm thinking it should give an error that lets them know they need to refresh the page and try again?

[jen-huang]

@LeeDr, the user will see an error that their version is out of date and they need to refresh. This was implemented in #18937, but broke due to some error formatting changes. This PR just adjusts for the updated format and restores the previous functionality 🙂