Failing test: Firefox XPack UI Functional Tests.x-pack/test/functional/apps/infra/link_to·ts - InfraOps app Infra link-to redirects to the logs app and parses URL search params correctly

[kibanamachine]

A test failed on a tracked branch

Error: retry.tryForTime timeout: Error: expected 'logFilter=(expression:\'trace.id:433b4651687e18be2c6c8e3b11f53d09\',kind:kuery)&logPosition=(position:(tiebreaker:0,time:1565707203194))&sourceId=default' to contain 'logFilter=(expression:\'trace.id:433b4651687e18be2c6c8e3b11f53d09\',kind:kuery)&logPosition=(position:(tiebreaker:0,time:1565707203194),streamLive:!f)&sourceId=default'
    at Assertion.assert (/dev/shm/workspace/kibana/packages/kbn-expect/expect.js:100:11)
    at Assertion.contain (/dev/shm/workspace/kibana/packages/kbn-expect/expect.js:442:10)
    at retry.tryForTime (test/functional/apps/infra/link_to.ts:37:67)
    at process._tickCallback (internal/process/next_tick.js:68:7)
    at onFailure (/dev/shm/workspace/kibana/test/common/services/retry/retry_for_success.ts:28:9)
    at retryForSuccess (/dev/shm/workspace/kibana/test/common/services/retry/retry_for_success.ts:68:13)

First failure: Jenkins Build

[elasticmachine]

Pinging @elastic/kibana-test-triage (failed-test)

[kibanamachine]

New failure: Jenkins Build

[kibanamachine]

New failure: Jenkins Build

[elasticmachine]

Pinging @elastic/logs-metrics-ui (Team:logs-metrics-ui)

[brianseeders]

This one has some additional failures that aren't currently included here:
https://kibana-ci.elastic.co/job/elastic+kibana+master/2510/execution/node/302/log/
https://kibana-ci.elastic.co/job/elastic+kibana+pipeline-pull-request/23049/execution/node/302/log/

[weltenwort]

@Zacqary could this be related to the log position state refactoring?

[Zacqary]

@weltenwort Yes, I noticed that the URL seemed to be including the streamLive:!f flag when it previously hadn't been before the refactor. Now it seems like it's gone back to not including that flag. I'll investigate and see if I can figure out why it's inconsistent.

[weltenwort]

thank you - maybe it's just a timing issue, meaning the test checks too early for it to be included. in that case a retry.try might be an easy way to stabilize

[Zacqary]

I've decided to just remove the possibility of having streamLive:!f in the URL and only make it set it to streamLive:!t when it's true, which I believe is how the URL state worked before the refactor. The streamLive param will now only be present if it's true and absent if it's false.