[Reporting/CSV] Do not fail the job if scroll ID can not be cleared

[tsullivan]

Summary

Closes #75594

Release note:

• Fixed an issue with CSV Export where a job could fail if clearing the scroll ID failed in Elasticsearch.

This PR avoids failing the CSV Reporting job if the call to clear the scroll fails. At that point, the CSV content has already been generated and is ready for export.

Reasons why Elasticsearch returns a 404 when called to clear a scroll:

If Elasticsearch can not find an active search context, it will return a 404 Not Found HTTP status code.

• If a clear scroll action was called on a non-existent (or already cleared) scroll_id.
  • Response {"succeeded":true,"num_freed":0} is returned by Elasticsearch when a scroll is cleared .
• The active scroll search context has been cleared by another "clear scroll" request.
• The active scroll search context has expired.

Checklist

Delete any items that are not applicable to this PR.

• Unit or functional tests were updated or added to match the most common scenarios

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[elasticmachine]

Pinging @elastic/kibana-reporting-services (Team:Reporting Services)

[tsullivan]

@elasticmachine merge upstream

[tsullivan]

@elasticmachine Merge upstream

[tsullivan]

@elasticmachine merge upstream

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 81ffec0

Build metrics

✅ unchanged

History

• 💚 Build #71122 succeeded 755a5a1
• 💚 Build #70628 succeeded 7abc6c6

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[joelgriffith]

Should we wrap these in a try/catch, or do:

return callEndpoint('clearScroll', { scrollId: [scrollId] }).catch((err) => {
        // Do not throw the error, as the job can still be completed successfully
        logger.warn('Scroll context can not be cleared!');
        logger.error(err);
});

[joelgriffith]

Just a matter of code/preference. The .catch is a bit more concise whereas the try/catch is more idiomatic async/await js

[tsullivan]

It definitely could go either way, in which case I like to defer to the existing async style in other code in the file. In this case, async/await follows the code style in this file

[tsullivan]

Thank @joelgriffith !