Kibana: Re-enable test: logstash grok debugger app syntax highlighting applies the correct CSS classes

[tylersmalley]

This test has been disabled due to its flaky behavior which was causing a disruption in productivity.

https://kibana-ci.elastic.co/job/elastic+kibana+6.x+multijob-x-pack/5/console

18:58:08    │ proc  [ftr]        └- ✖ fail: "logstash grok debugger app syntax highlighting applies the correct CSS classes"
18:58:08    │ proc  [ftr]        │        [GET http://localhost:9515/session/a12d2fb74d95b13ff539262cd6754946/element/0.4348425826514668-35/text] stale element reference: element is not attached to the page document
18:58:08    │ proc  [ftr]        │         (Session info: chrome=68.0.3440.106)
18:58:08    │ proc  [ftr]        │         (Driver info: chromedriver=2.36.540471 (9c759b81a907e70363c6312294d30b6ccccc2752),platform=Linux 4.15.0-1015-gcp x86_64)
18:58:08    │ proc  [ftr]        │         at Server._get (/var/lib/jenkins/workspace/elastic+kibana+6.x+multijob-x-pack/kibana/test/functional/services/remote/verbose_remote_logging.js:34:21)
18:58:08    │ proc  [ftr]        │         at runRequest (/var/lib/jenkins/workspace/elastic+kibana+6.x+multijob-x-pack/kibana/node_modules/leadfoot/Session.js:92:40)
18:58:08    │ proc  [ftr]        │         at getFinalValue (/var/lib/jenkins/workspace/elastic+kibana+6.x+multijob-x-pack/kibana/node_modules/dojo/_debug/Promise.ts:462:22)
18:58:08    │ proc  [ftr]        │         at /var/lib/jenkins/workspace/elastic+kibana+6.x+multijob-x-pack/kibana/node_modules/dojo/_debug/Promise.ts:478:11
18:58:08    │ proc  [ftr]        │         at /var/lib/jenkins/workspace/elastic+kibana+6.x+multijob-x-pack/kibana/node_modules/dojo/_debug/Promise.ts:393:16
18:58:08    │ proc  [ftr]        │         at runCallbacks (/var/lib/jenkins/workspace/elastic+kibana+6.x+multijob-x-pack/kibana/node_modules/dojo/_debug/Promise.ts:11:12)
18:58:08    │ proc  [ftr]        │         at /var/lib/jenkins/workspace/elastic+kibana+6.x+multijob-x-pack/kibana/node_modules/dojo/_debug/Promise.ts:317:5
18:58:08    │ proc  [ftr]        │         at run (/var/lib/jenkins/workspace/elastic+kibana+6.x+multijob-x-pack/kibana/node_modules/dojo/_debug/Promise.ts:237:8)
18:58:08    │ proc  [ftr]        │         at /var/lib/jenkins/workspace/elastic+kibana+6.x+multijob-x-pack/kibana/node_modules/dojo/_debug/nextTick.ts:44:4
18:58:08    │ proc  [ftr]        │         at _combinedTickCallback (internal/process/next_tick.js:131:7)
18:58:08    │ proc  [ftr]        │         at process._tickCallback (internal/process/next_tick.js:180:9)
18:58:08    │ proc  [ftr]        │       

[tylersmalley]

@ycombinator, not sure if you are still working on the Grok Debugger.

[bmcconaghy]

@tylersmalley FYI Ingestion owns grok debugger, not management team.

[ycombinator]

I am not, but @justinkambic should be able to look at this one. Also cc: @simianhacker.

[jen-huang]

Occurred in a 6.4 backport as well: https://kibana-ci.elastic.co/job/elastic-kibana-pull-request/129/

[tylersmalley]

It appears this is pretty consistent on the 6.4 branch - can we confirm this is not an actual issue?

[ycombinator]

The grok debugger code hasn't been touched in months (AFAIK) so it's strange that this is suddenly failing now but didn't fail on any PRs that might've introduced some change that is causing it to fail. I'd suggest skipping the test for now until @justinkambic or someone else from the Ingest UI team (@simianhacker?) gets a chance to dig into it some more.

[ycombinator]

Also pinging @mattapperson

[justinkambic]

@ycombinator if you recall I was running into what I think are similar problems when I was attempting to write highlighting tests for the work I'm doing on Pipeline Management's editor as well. Those tests were also flaky and would sometimes succeed a dozen times in a row and then fail with the same error message.

[ycombinator]

Ah yes, I do recall now, @justinkambic. I'm just surprised that these grok debugger tests started failing recently after several weeks of not failing (AFAIK). I'm not sure what that means specifically but maybe there's a clue to the flakiness there?

[justinkambic]

@ycombinator is it possible that it has been failing awhile, but people were just re-doing their CI build and having it pass, and thinking nothing of it? Or do we know it only started failing recently?

[ycombinator]

I only started hearing about it failing recently (about ~3 weeks ago) but it's possible people were just re-running their CI and having it pass before then.

[LeeDr]

@tylersmalley is there broken functionality or just the tests? If it's just the tests can we remove the blocker label? Looks like nobody's touched this in almost a month.

[tylersmalley]

@LeeDr I don't know, I disabled it because it was flaky - I assume it needs to be investigated to confirm.

[stacey-gammon]

Still has the blocker label. Any updates @justinkambic or @simianhacker? Should we remove the blocker label? Or bump the version number to... 6.6?

[justinkambic]

As far as I know we only ever had issues with the tests passing, I'm not aware of any movement on this issue.

[stacey-gammon]

Sounds like the test is still being skipped. If the flakiness was in error, should it be turned back on? Or if the test is not useful, perhaps just deleted? Or am I wrong in that the test has already been turned back on and this issue can be closed?

[rayafratkina]

Any updates on this?

[stacey-gammon]

I'm removing the blocker label, until a team takes ownership there really is no point, and it's been filed for 6 months.