Error: "Id collision" when re-loading data with collapsed group

[vic]

It seems there is a bug when the "grouping" feature is used. It occurs when data is re-loaded while a group is collapsed. The error shown is:

Uncaught (in promise) Error: Id collision on <list of ids>

To reproduce:
- Go to the "grouping" demo: https://www.bryntum.com/examples/scheduler/grouping/
- In the developer console, run "scheduler.crudManager.load()". This reloads the data => this is OK.
- Collapse a group (for example, the first group, "Consultants").
- In the developer console, run "scheduler.crudManager.load()". The error occurs! See screenshot.

Screenshot from 2019-09-02 10-07-12.png (45.54 KiB) Viewed 2413 times

This occurs in the Bryntum Scheduler grouping example which is currently online (version 2.2.3).


Can anybody help me with this bug? I would like to get rid of this, or bypass it if necessary. Simply catching the error will not solve the problem, since the rows within the group will be duplicated when the group is opened again (and the group counter will be double the correct value).

[mats]

Thanks for reporting, definitely a bug. Ticket to track here: https://app.assembla.com/spaces/bryntum/tickets/9158-crash-when-reloading-crud-manager-if-a-group-is-collapsed/details#

[vic]

Thanks for the tracking link! I also appreciate giving this bug high priority. If you know when this will be fixed--or if you figure out a work-around--I'd be glad to hear it.

[mats]

Can't know after 3 minutes of creating the issue Please track ticket for info, as soon as it's Resolved you can find fix in nightly builds.

[vic]

Hi Mats,

According to the ticket tracker information, the issue is Resolved. Can you confirm for me that it is included in the nightly builds? I still get the same errors when using the latest two nightly builds...

[mats]

Yes it should be fixed. How do you reproduce the error?

[vic]

Hi Mats,

I think I made a mistake. When using the nightly "next" build, the error still persisted. But when I tried the "release" build, the issue was solved. Thank you!

I did still notice some strange behavior in this area (loading while groups are collapsed), which tells me that maybe the resources are not merged as perfectly as one might expect. Unfortunately, I do not have the time right now to investigate if this is due to my usage of your scheduler, or due to the scheduler itself.

A short description of what happens:

When performing the same actions as used to trigger the above bug (1. Collapse a group; 2. Call scheduler.crudManager.load()), I find that the count of the group size displayed in the group headers may change even though no server-side data change has occurred. I say "change" without specifying the change, because sometimes it increments by 1, sometimes it decrements by 1. Furthermore, when re-opening the group, the either the first or the last resource row is duplicated.

Repeated calls to scheduler.crudManager.load() does not change the data again, until another group is collapsed (or uncollapsed). Then a new iteration of changes to the group counts and duplicated rows occurs.


As I said: unfortunately I do not have time to delve deep into this issue and see if it is my usage of the scheduler that causes this. But I do not override the ResourceStore, nor do I override the CrudManager.

If a full update of the scheduler is released (and the examples on your site are updated), I can try to see if I can reproduce the issue there, but I thought to mention this issue before that time. I hope that the description is clear enough for you to have a look at it. If so, please let me know what you find!

[pmiklashevich]

Hello,

The behaviour you described sounds familiar. Groping feature works bad with filters enabled. Please see this ticket: https://app.assembla.com/spaces/bryntum/tickets/9176-filterbar-and-group-feature-duplicate-records/details

Do you use filters in your project? If so, please turn them off to see if it helps. If the bug is still there please wrap it up in a testcase so we can check.

Thanks,
Pavel

[vic]

Hi Pavel,

Thanks for your interest in the bug. I have checked, but I cannot find any filter-feature that is actively enabled in my project. Furthermore, the "eventFilter" feature (which is enabled by default) is actively set to FALSE in the config used to create the scheduler.

Just to make sure, I also set the features "filter" and "filterBar" to FALSE in this config.

The issue still occurs, so unfortunately I suspect this is not related to filtering.

Unfortunately, I do not have time to create a good (simplified) test-case version of the code I'm working with. My apologies for that. If I find the time, I'll be sure to make one. All I have for now is the description of my use-case above, and the following screenshots of what I see happening:

1. Page load, everything is initialized
2. Collapse group "Ongegroepeerd (108)", see image

Screenshot from 2019-09-05 15-52-19.png (28.36 KiB) Viewed 2376 times

3. Call scheduler.crudManager.load()
4. See image

Screenshot from 2019-09-05 15-53-24.png (26.84 KiB) Viewed 2376 times

When opening the group "Ongegroepeerd (109)", the first resource row is duplicated. Please also note that "Berry Homenick" (from "Y groep") has also disappeared in this action.

No changes serverside have happened in between the initial load and the collapsed load.

[pmiklashevich]

To be able to solve this issue we have to be able to reproduce it first. For further assistance with this issue please provide steps to reproduce with one of our demos or a full runnable testcase. Thanks!