Failing test: Chrome X-Pack UI Functional Tests.x-pack/test/functional/apps/lens/drag_and_drop·ts - lens app lens drag and drop tests should move the column to compatible dimension group

[kibanamachine]

A test failed on a tracked branch

Error: expected [ 'Top values of clientip' ] to sort of equal [ 'Top values of @message.raw' ]
    at Assertion.assert (/dev/shm/workspace/parallel/3/kibana/packages/kbn-expect/expect.js:100:11)
    at Assertion.eql (/dev/shm/workspace/parallel/3/kibana/packages/kbn-expect/expect.js:244:8)
    at Context.<anonymous> (test/functional/apps/lens/drag_and_drop.ts:78:96)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
    at Object.apply (/dev/shm/workspace/parallel/3/kibana/packages/kbn-test/src/functional_test_runner/lib/mocha/wrap_function.js:84:16) {
  actual: '[\n  "Top values of clientip"\n]',
  expected: '[\n  "Top values of @message.raw"\n]',
  showDiff: true
}

First failure: Jenkins Build

[elasticmachine]

Pinging @elastic/kibana-app (Team:KibanaApp)

[jbudz]

skipped
main: 9f09c84
7.x: af2df41

[wylieconlon]

This is one of the stranger failures, we need to figure out what's happening here:

[kibanamachine]

New failure: Jenkins Build

[spalger]

Two failures, one in 7.x and one in a PR to 7.11 since this was fixed. Do you have a chance to look at this again @flash1293?

[flash1293]

Seems like this can still happen:

I checked the code and I realized we are doing this to simulate dragging:

          const dragStartEvent = createEvent('dragstart');
          dispatchEvent(origin, dragStartEvent);

          setTimeout(() => {
            const dropEvent = createEvent('drop');
            dispatchEvent(target, dropEvent, dragStartEvent.dataTransfer);
            const dragEndEvent = createEvent('dragend');
            dispatchEvent(origin, dragEndEvent, dropEvent.dataTransfer);
          }, 50);

@wylieconlon Do you think it's possible the 50ms just haven't passed yet and the drag is not completed but still in progress? Or maybe the other way around, the drop event came in too early and couldn't be processed? I will prepare a PR increasing the waiting times a bit here but I think we have to test it "in the wild" by merging into master because this issue is pretty rare (happened 3 times in 30days, so flaky test runner would need a lot of cycles to rule it out).

[wylieconlon]

@flash1293 It does seem possible that 50ms is not enough to execute a state update, since a state update is needed to mark that the drag has started. Specifically we use this code on start:

    // Chrome causes issues if you try to render from within a
    // dragStart event, so we drop a setTimeout to avoid that.
    setState({ ...state });
    setTimeout(() => setDragging(value));

So we probably have some underlying performance issues here, but I agree that increasing the timeout is a solution that would help.