Looking into unit test failures

BTW, ready for review

Codecov Report

Attention: Patch coverage is 23.72881% with 90 lines in your changes missing coverage. Please review.

Project coverage is 46.68%. Comparing base (e3aa392) to head (e588409).
Report is 16 commits behind head on main.

@@            Coverage Diff             @@
##             main    #2110      +/-   ##
==========================================
+ Coverage   46.60%   46.68%   +0.08%     
==========================================
  Files         679      691      +12     
  Lines       38408    38587     +179     
  Branches     9687     9622      -65     
==========================================
+ Hits        17901    18016     +115     
- Misses      20455    20560     +105     
+ Partials       52       11      -41     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Looking into failures here

Weird that the failures are only occurring on chromium, but I believe the reason of the failure is that we expect to have the pickers accessible in 1.5s, but now, with the new logic, the pickers are disabled while the partitionConfig.mode === 'empty', which in some cases (like the vid below), is not the case.

The reason we do this is so that when we have an empty partition table, we wanted to have the pickers disabled. But even for a table with rows, the table will have 0 rows of length (and thus, will be considered empty) momentarily.

We could either change the benchmark to be 20000ms instead of 15000ms, or we could look at adding a specific "temporarily empty" config mode, which would somehow differ then the "empty" mode (which would now act as more of a forever empty mode).

The latter will be difficult to implement though, since the event listener listens for when the table is updated and then changes the mode accordingly, so I am not sure how before the event, it will differentiate between a table that will be forever empty, and one that is just empty until the data loads in.

@mofojed @dsmmcken any thoughts?

We've already got the loading state for when it's still loading. The empty state is for when the table is empty, there's no need for a forever empty state; an empty table could eventually tick in data (it could be in one second, one minute, one hour, we don't really know).
That being said - the failures in the e2e tests are not with the partitioned tables? Where are you seeing that the disabled pickers is affecting the e2e tests? Look at the report attached: https://github.com/deephaven/web-client-ui/actions/runs/9845185336/artifacts/1682155129
Looking at the report it's looking for a context menu that does not appear for some reason.

No actually, that does not fix the issue we are facing with the spinner, ignore.

Been doing some more investigations, the firefox and cjromium failures here are not consistent. On one run they fail, but then if I re-run those jobs, they pass. The inconsistent behaviour makes me think there may be a race condition or some weird code circumstance in the code responsible for rendering the context menu.

The only change I made to the Context Menu was adding the View Constituent Table option, but I am unsure why that would result in the whole context menu not loading, need to dig more.

Yeah I have been trying to debug the e2e failures, but it is slightly tricky, will continue to debug and then we can debug together as well in our 1:1, will make the requested change with -1 rn.