support icon indicating copy to clipboard operation
support copied to clipboard

Async cell renderer can throw if the Row being rendered is destroyed during the await.

Open chuckn0rris opened this issue 10 months ago • 6 comments

Forum post

In the new version of Bryntum Gantt/SchedulerPro, the following error is appearing:

TypeError: this.updateCellContent is not a function, which did not occur in previous versions.

Additionally, I’m also seeing the message this.rowManager is undefined.

I'm not sure if these two errors are related, but I've noticed issues specifically in Mozilla Firefox, where rows sometimes fail to load and appear empty. This behavior does not happen in other browsers.

I’ve attached screenshots and a video showing the errors. I’ll be on standby for any updates or recommendations.

Thank you in advance.

foRUM.png Captura de pantalla 2025-04-16 110108.png

Note: This type error appears in all browsers, however, in Mozilla Firefox, there's a specific issue where rows sometimes fail to load and remain empty. When checking the Firefox console, this same type error is also displayed. foRUM.png Captura de pantalla 2025-04-16 110108.png

xos-frontend-pilot (1).zip

chuckn0rris avatar Apr 24 '25 09:04 chuckn0rris

The problem here is related to the "double run" of the React 18+ application in strict development mode. In this mode React (not Bryntum) starts the application, then immediately stops it and starts it again. The process and its purpose is explained by React guys here: https://react.dev/reference/react/StrictMode#fixing-bugs-found-by-double-rendering-in-development and the whole chapter thereof.

I found that after first run, Bryntum ColumnStore (and probably the other stores and/or components) are still being destroyed when an attempt is made to access this store (see the screenshot).

Now, the React application is responsible to not leave any artifacts or keep old references in closures of unfinished promises or asynchronous functions after it is destroyed, before it is re-run.

Image

So it is most likely not a Bryntum regression bug.

jsakalos avatar Apr 28 '25 07:04 jsakalos

@jsakalos In our main production application, we are not using StrictMode. However, even after removing that configuration from the file, the error still appears. Additionally, the issue where the picture column image disappears after moving it to another position still persists. On the other hand, after downgrading all the thin packages to version 6.1.3 in the package.json, the updateColumn error and the bug where the image disappears when moving the picture column are no longer present.

xos-frontend-pilotV2.zip

npm run json-server npm run start

On the other hand, I am attaching the test project using version 6.1.3 overall, and you will see that no errors are present. However, if you update to the latest version, you will notice that the error reappears.

juanprog97 avatar Apr 28 '25 16:04 juanprog97

@juanprog97, interesting. I'll check that. The mystery is that the store is destroyed. I'll post here the results.

jsakalos avatar Apr 29 '25 18:04 jsakalos

@juanprog97 preliminary/incomplete: The problem lies in the asynchronous renderer (configBryntum.tsx:59). If you could make it non-async it could help as a workaround. However, I'll discuss it with a developer who implemented the change that may be a culprit of the problem.

jsakalos avatar Apr 30 '25 08:04 jsakalos

@juanprog97, as you can see, we have fixed the crash, however, the renderer code is still complex and can introduce some racing conditions or unwanted behavior. The idea of renderer is by itself very simple: return an html string to be shown in the cell.

In your case, the async function getColumns first removes all columns from the column store and then re-adds them. That leads to the destruction of the columns but one of the renderers is also async. So we can wind up with the code running in various stages of destruction.

Ideally, the renderer should be as simple as possible and the nested async functions should also be simplified.

Anyway, your code should not crash starting from the next release.

jsakalos avatar Apr 30 '25 11:04 jsakalos

@jsakalos @ExtAnimal thanks

juanprog97 avatar Apr 30 '25 13:04 juanprog97