You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hypothesis 99.999% confirmed: The problem appears to result from the backend pushing messages to the frontend on a cell-by-cell basis. On a sufficiently large (wide/tall) dataset, the outgoing message queue fills up, and the cells are dropped.
76a65bc added a tempoorary workaround, bumping the spreadsheet queue up to a sufficiently large size that this is unlikely to happen during normal scrolling. By my rough estimates, we should be able to handle a few hundred columns without the problem surfacing again.
That said, the correct way to solve this is to modify the backend to group messages into rows. The protocol supports row-level notification, but SingleRowExecutor operates at the granularity of individual cells. The specific code path of interest involves:
The user scrolls to a new region of the spreadsheet
The frontend subscribes to rows in the region.
The backend socket relays the subscription request, which eventually makes its way into SingleRowExecutor.subscribe
SingleRowExecutor.subscribe calls SingleRowExecutor.recompute for each individual cell.
SingleRowExecutor.recompute takes responsibility for notifying the frontend of 'changes' (i.e., the value of cells in the newly subscribed rows)
I'm not entirely sure what the best way to fix this is, but what I'm leaning towards right now is to have subscribe take responsibility for notifying the frontend. e.g., add a notify parameter to recompute (to disable notification) and have subscribe send a full row update once the cell values have been computed.
- Increase the spreadsheet socket outgoing message buffer size. 100k slots should be enough to keep up with most scrolling through the spreadsheet.
The *correct* way to fix this, is to change SpreadsheetExecutor/SingleRowExecutor to support notifying on full-row updates, rather than on a cell-by-cell basis (which it does right now). This shouldn't be too hard, since SingleRowExecutor operates at the granularity of rows anyway... but I want to have the time to do it right (which is not the case right now OK).
Describe the bug
Certain rows and/or cells don't load properly in a spreadsheet (instead of cell contents, you get a spinner).
To Reproduce
The bug is transient. On a sufficiently large dataset, it seems to happen to a random set of cells each time.
Expected behavior
All cells load properly
The text was updated successfully, but these errors were encountered: