Scheduling cycle still reproducible on FixedUnits / FixedEffort time-phased tasks after the #13519 fix

[lemes]

Forum post · Follow-up to #13519 (fixed in https://github.com/bryntum/bryntum-suite/pull/14757, merged 2026-08-20 into release, slated for 7.3.6)

Summary

The fix for #13519 removes the intra-task Scheduling cycle for the reported gesture (single FixedEffort task, one segment, set segment start then end in the task editor's Resources tab), and the two regression tests added in #14757 pass. However, The reporting customer's QA team validated the nightly build containing that fix and reports the cycle is still reproducible on FixedUnits and FixedEffort tasks with time-phased assignments:

The original report is fixed in our nightly build, but we can still reproduce this for Fixed Units and Effort which is a concern for us.

Internal status as of 2026-09-09: "#13519 initially solved but still fails for an edge case". This issue tracks the residual so #13519 can stay closed against the scenario it fixed and the remaining case gets its own reproduction, fix and tests.

What is known

SchedulerProTimePhasedAssignmentMixin#calculateShrinkDate (from #14757) only breaks the task.$.endDate → assignment.$.startDate → assignment.$.units → task.$.endDate strongly connected component when selector.isDurationDefinedByEffort && selector.hasInputOnTimePhasedData. The PR description already lists cycles that survive it:

1. FixedUnits + editing the task's total effort while it has 2+ segments still cycles through a different component: TASK.effort → earlySchedule.startDate → TASK.startDate → ASSIGN.startDate → ASSIGN.effort → TASK.effort.
2. FixedEffort ALAP / Backward cycle through the project schedule (pre-existing, distinct component). Now tracked separately as Backward FixedEffort task cycles when populating time-phased segment dates #13718.
3. hasInputOnTimePhasedData excludes effort/units input (pre-existing TODO), so segment edits that arrive as effort/units rather than dates never take the proposed-layer branch of the clamp.

Related reports from the same customer sweep (2026-09-05) that may be the same residual seen from different gestures: #13713 (FixedEffort, split segments + finish constraint), #13712 (FixedUnits, raising effort of split assignment), #13734 (FixedUnits + effort + explicit segments rejects initial commit), #13714 (FixedEffort, deleting one of three segments).

Reproduction

Exact customer steps for the residual are not yet available; the customer confirmed only the scheduling mode and that the original #13519 steps are fixed. Until they are, the matrix that #14757 did not cover is the starting point, using examples/resourceutilization with showTimePhasedAssignmentsGrid : true as in #13519:

• FixedUnits task, 2+ segments, edit the task total effort (scenario 1 above).
• FixedUnits / FixedEffort task, 2+ segments, edit a segment's effort or units rather than its dates (scenario 3 above).
• FixedEffort / FixedUnits task, add a segment with ResourcesTab#onAddTimePhasedClick next to dated ones, then date it.
• FixedEffort / FixedUnits task, remove a segment.
• Any of the above with effortDriven : true.

Expected

The edit is applied. No Scheduling cycle dialog. Task dates, effort and units settle according to the task's scheduling mode contract (for FixedEffort: effort held, units/duration flex; for FixedUnits: units held, effort/duration flex).

Actual

A cycle has been found, formed by: "<task>" -> "<task>" with an empty dependency dropdown, so the only option is to cancel the edit and the segment data is lost.

Next steps

• Ask the reporter (forum topic 35607) for the exact task shape and edit sequence they used on the nightly build, and add it to Engine/tests/quark/gantt_scheduling/time_phased_assignments/.
• Reproduce the matrix above on current release (with #14757) and record which combinations still cycle, with the ChronoGraph cycle path for each.
• Fix the surviving component(s) at the engine level, same approach as #14757 / 9969244c0b2 (remove the inverted edge rather than tolerate the cycle).
• Reply on the forum topic once the residual is confirmed and scheduled.