Unpaired resumeChangeTracking() throws on vetoed task edit with suspendHasChangesEvent

[marciogurka]

Forum post

Failing test case:

t.it('Should not resume change tracking when task edit is vetoed', async t => {
    gantt = await t.getGanttAsync({
        features : { taskEdit : { suspendHasChangesEvent : true } }
    });

    gantt.on('beforeTaskEdit', () => false);

    await gantt.editTask(gantt.taskStore.getById(13));

    await gantt.project.commitAsync();

    t.pass('Vetoed task edit did not fire an unpaired resumeChangeTracking');
});

"Hi Team,

We are getting an error, when cell is edited quickly and the task editor is opened.

Steps:
Fast-edit a Duration cell.
Immediately open the task editor for that row.

Error:
Uncaught (in promise) Error: No matching startFilterBatching call

Reproducible in latest version - 7.3.5
Video: Attached videos

Minimal example is attached
Run npm install && npm run dev
Open the url in browser
Open Console,
Click Change duration + open task editor."

[zenbanbryntum]

Reproduced with a failing Siesta test.

Test file: Gantt/tests/feature/TaskEditEvents.t.js

The test supplied in the issue body reproduces the bug as written — it is placed verbatim into the existing TaskEditEvents.t.js (which already hosts the sibling Should be possible to cancel show and Should not trigger change events on project while editing task cases).

t.it('Should not resume change tracking when task edit is vetoed', async t => {
    gantt = await t.getGanttAsync({
        features : { taskEdit : { suspendHasChangesEvent : true } }
    });

    gantt.on('beforeTaskEdit', () => false);

    await gantt.editTask(gantt.taskStore.getById(13));

    await gantt.project.commitAsync();

    t.pass('Vetoed task edit did not fire an unpaired resumeChangeTracking');
});

Failing output (identical across 3 consecutive runs — the failure is fully deterministic, not intermittent):

Should not resume change tracking when task edit is vetoed
    fail 1 - Unhandled promise rejection during the test: [Should not resume change tracking when task edit is vetoed]
    Error: No matching `suspendFilterOnUpdate` call
        at CalendarManagerStore.resumeFilterOnUpdate (Core/data/mixin/StoreFilter.js:867:19)
        at Scheduler/crud/AbstractCrudManagerMixin.js:1363:23
        at Array.forEach (<anonymous>)
        at ProjectModel.resumeChangeTracking (Scheduler/crud/AbstractCrudManagerMixin.js:1362:29)
        at TaskEdit.onEditRecordPrevented (SchedulerPro/feature/TaskEditBase.js:249:21)
        at async TaskEdit.doEditRecord (SchedulerPro/feature/TaskEditBase.js:396:13)

0 passed, 2 failed assertions

This is the same unbalanced store suspend/resume family as the user-reported No matching startFilterBatching call — an unpaired resume walking the project's stores.

Root-cause pointer: In SchedulerPro/lib/SchedulerPro/feature/TaskEditBase.js, doEditRecord() calls client.project.suspendChangeTracking() (~line 334) inside the if (await me.triggerOnClient('beforeRecordEdit', ...) !== false) branch, so the suspend only ever runs once the veto check has passed. When a beforeTaskEdit listener returns false, control instead takes the else branch (~line 396), which calls onEditRecordPrevented(true). That method unconditionally calls project.resumeChangeTracking() whenever suspendHasChangesEvent is set (~lines 248-250), with no check that a matching suspend actually happened. The resume fans out through AbstractCrudManagerMixin.resumeChangeTracking() (~line 1362) into resumeFilterOnUpdate() on every store, and StoreFilter.resumeFilterOnUpdate() throws because its suspend counter is already zero. The same unguarded-resume shape also exists in the onDelete path (~line 729).