[Uptime] Increase timeout in attempt to fix skipped a11y test

[justinkambic]

Summary

Code is WIP.

Fixes #72994.

We have a few skipped a11y tests in master. At least one of these is resulting of an underlying Uptime helper function, rather than actual availability-related problems. This patch should fix that.

Checklist

Delete any items that are not applicable to this PR.

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
• This was checked for keyboard-only and screenreader accessibility
• This renders correctly on smaller devices using a responsive layout. (You can test this in your browser
• This was checked for cross-browser compatibility

For maintainers

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

[justinkambic]

Passed a round of flaky test runner: https://kibana-ci.elastic.co/job/kibana+flaky-test-suite-runner/653/

[justinkambic]

Second round of flaky test runner passed: https://kibana-ci.elastic.co/job/kibana+flaky-test-suite-runner/659/

[elasticmachine]

Pinging @elastic/uptime (Team:uptime)

[justinkambic]

Third round of flaky test runner passed x100 executions: https://kibana-ci.elastic.co/job/kibana+flaky-test-suite-runner/662/

[justinkambic]

@elasticmachine merge upstream

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 5faa19b

Build metrics

✅ unchanged

History

• 💚 Build #64032 succeeded 9d77f97
• 💚 Build #63950 succeeded 526f3d3b50daf8ff26b74cc58b31bc178ca77b7a
• 💚 Build #63943 succeeded 3541ae4cf98e2a15b944c2af573d67b0c677a00a

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

[shahzad31]

LGTM !!

[spalger]

I don't see any problems with this, though my instincts say that overriding the default timeouts isn't a good idea. I have no idea how those timeouts are chosen, but it seems like a tricky game to play...

[justinkambic]

@spalger do you recommend removing the custom timeout altogether? This test was just failing because 2kms was too short, but I'm fine with removing that and simply relying on the default. I don't think it will impact anything.

I only added the greater value as a quick fix, I didn't really give it much thought.

[spalger]

@spalger do you recommend removing the custom timeout altogether?

In general, yes. I think trying to manage timeouts manually is tricky business and will lead to a great deal of flakiness unless folks are managing them pretty carefully and with the considerations of the potentially very surprising delays we see in CI caused by us running so much at one time in VMs. I'm not necessarily recommending doing it right now, but I think in general it's an anti-pattern to override the defaults unless there's a clear reason for it.

[justinkambic]

Ok thanks. I can bring this up in my team's next technical sync that we should aim to remove these unless we can provide a justification for each one.

[justinkambic]

Backported to:

• 7.9/7.9.0 14c59d8
  [7.9] [Uptime] Increase timeout in attempt to fix skipped a11y test (#73078) #73346
• 7.x/7.10.0 e7c7412
  [7.x] [Uptime] Increase timeout in attempt to fix skipped a11y test (#73078) #73345