GridCore dataController: reset guard flags when the guarded action throws

[bit-byte0]

What

The data controller's guard flags (_columnsUpdating, _skipProcessingPagingChange) now reset even when the guarded operation throws. Previously a throw in updateSortingGrouping skipped _columnsUpdating = false and wedged the controller, permanently suppressing later sorting/grouping columnsChanged events.

How

Both guarded blocks are wrapped in try/finally so the flags reset even if the operation throws.

[Copilot]

Pull request overview

This PR hardens the Grid data controller’s internal guard flags so they always reset even when guarded operations throw, preventing the controller from getting “wedged” and suppressing later sorting/grouping or paging processing.

Changes:

• Introduces a small guard utility (runGuarded) with a mutable Flag object to ensure flags are lowered via try/finally.
• Adds Jest tests validating createFlag and runGuarded behavior (including the throwing path).
• Updates DataController to use runGuarded for sorting/grouping and paging guard sections, and switches boolean checks to .value.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
packages/devextreme/js/__internal/grids/grid_core/data_controller/utils/guards.ts	Adds a helper to raise/lower guard flags around a critical section using try/finally.
packages/devextreme/js/__internal/grids/grid_core/data_controller/utils/tests/guards.test.ts	Adds Jest coverage for the new guard helper (flag raising/lowering + throwing path).
packages/devextreme/js/__internal/grids/grid_core/data_controller/data_controller.ts	Replaces manual flag toggling with runGuarded and updates guard checks to use Flag.value.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (1)

packages/devextreme/js/__internal/grids/grid_core/data_controller/utils/guards.ts:5

• For consistency with other utils in this folder, exported helpers are declared as functions (e.g. utils/paging.ts:3 export function resolvePaginate, utils/row_values.ts:6 export function generateRowValues). Consider switching createFlag from an exported const to an export function as well.

export const createFlag = (): Flag => ({ value: false });

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (2)

packages/devextreme/js/__internal/grids/grid_core/data_controller/data_controller.ts:1595

• Consider adding a Jest regression test for the paging guard that forces an exception during paging option application (e.g., make dataSource.pageIndex/dataSource[optionName] throw) and asserts _skipProcessingPagingChange is cleared in all cases. Without a test, it’s easy for future edits to reintroduce the stuck-flag issue.

    this._skipProcessingPagingChange = true;
    try {
      if (optionName === 'pageSize' && value === 0) {
        dataSource.pageIndex(0);
        this.option('paging.pageIndex', 0);

packages/devextreme/js/__internal/grids/grid_core/data_controller/data_controller.ts:443

• Consider adding a Jest regression test that simulates columnsController.updateSortingGrouping(...) throwing and verifies the controller doesn’t stay wedged (i.e., _columnsUpdating is reset to false, so subsequent sorting/grouping columnsChanged can proceed). This change is specifically about exception safety and is hard to validate without a test.

This issue also appears on line 1591 of the same file.

    this._columnsUpdating = true;
    try {
      columnsController.updateSortingGrouping(dataSource, !this._useSortingGroupingFromColumns);
    } finally {
      this._columnsUpdating = false;