Recover from rejected changes#

Get an editor working again after apply rejects part of a change set, without restarting the app or losing the user's edits.

When apply rejects an operation, the project sets needsResync. From then on, solve(null, …), apply and level throw ProjectException with code ProjectError.NEEDS_RESYNC. Reads that need a baseline (preview, loadProfile, evaluate, suggestAssignments) throw ProjectError.NO_BASELINE. To clear the flag, reload the full data with solve(data, …). See Editing a project for why.

Prerequisites#

A long-lived Project solved once with solve(data, …).
Your own model that can produce the full ProjectData the user expects to see. You resync from this data.

Steps#

Apply the change set and keep the ApplyReport:
```
var report = project.apply(changes);
```
If apply throws a ProjectException, nothing was applied: NEEDS_RESYNC comes from an earlier rejection, STALE_BASELINE from a baselineId that isn't current. A rejection inside the batch doesn't throw.

Check needsResync. If it's false, continue as usual with solve(null, …):

if (!report.needsResync) {
  project.solve(null, new SolveOptions());
}

Show the user what was refused. Each RejectedOperation has the operation's path (such as tasks.remove[0]) and a message:
```
for (var op : report.rejected) {
  System.err.println("rejected " + op.path + ": " + op.message);
}
```
The other operations in the batch were applied. A rejected operation leaves no partial edit behind.
Make your model hold the state you want. Undo the rejected edits in it, or keep it as is if it's already correct. Don't try to repair the project with more apply calls: they throw NEEDS_RESYNC.
Resync with the full data. Set includeUnchanged so the result carries the dates of every task, not only the ones that moved:
```
var resync = new SolveOptions().withIncludeUnchanged(true);
var result = project.solve(model, resync);
```
solve deep-copies model, so later edits to your model don't leak into the project.
Write every entry of result.updates back into your UI. The engine's state may differ from what the UI shows, so refresh all task dates, not just the edited ones.
Take the new baselineId from result for the next preview or change set. Tokens from before the resync are stale.

The full example below stretches one task and, in the same batch, removes a task the engine doesn't have:

import java.util.List;
import org.dhtmlx.plen.*;

public class RecoverFromRejectedChanges {
  public static void main(String[] args) throws Exception {
    var jan5 = Moment.fromYmdHm(2026, 1, 5, 0, 0);

    // The editor's own model: the data you resync from.
    var model = new ProjectData()
        .withTasks(List.of(new TaskData(Id.str("design")).withStartDate(jan5).withDuration(2.0)));
    // 24/7 time keeps the example dates easy to check.
    model.config.useCalendars = false;

    var project = new Project();
    project.solve(model, new SolveOptions());

    // The user stretches "design" to 4 days. The UI also sends a removal
    // of "review", a task the engine never had.
    model.tasks.get(0).duration = 4.0;
    var changes = new SchedulingChanges();
    changes.tasks.update.add(new TaskUpdate(Id.str("design")).withDuration(Patch.of(4.0)));
    changes.tasks.remove.add(Id.str("review"));

    var report = project.apply(changes);
    if (!report.needsResync) {
      project.solve(null, new SolveOptions());
      return;
    }

    for (var op : report.rejected) {
      System.err.println("rejected " + op.path + ": " + op.message);
    }

    var resync = new SolveOptions().withIncludeUnchanged(true);
    try {
      var result = project.solve(model, resync);
      for (var m : result.updates) {
        System.out.println(m.id + " " + m.startDate + ".." + m.endDate);
      }
    } catch (InputException e) {
      // The project keeps its state and still needs a resync.
      System.err.println("resync data invalid at " + e.path + ": " + e.getMessage());
    }
  }
}

When the resync data is invalid#

The resync goes through the same validation as the first load. If your model produces invalid data, such as a duplicate task id, solve(data, …) throws InputException with the field path in path, for example tasks[1].id. The project keeps its previous state and still throws NEEDS_RESYNC. Fix the data and call solve(data, …) again. See Error handling for the full list of validation errors.

When you didn't check the report#

If some code path skipped needsResync, the next apply or solve(null, …) throws. ProjectException is unchecked, so catch it where you send edits and resync on NEEDS_RESYNC:

try {
  project.apply(changes);
  project.solve(null, new SolveOptions());
} catch (ProjectException e) {
  if (e.code != ProjectError.NEEDS_RESYNC) throw e;
  project.solve(model, new SolveOptions().withIncludeUnchanged(true));
}

apply checks NEEDS_RESYNC before anything else, so the change set in that call isn't applied. Put its edits in your model before the resync.

Drop the edit instead of resyncing#

To avoid a full reload, apply the change set to a copy first. copy() is cheap, and a rejection on the copy doesn't touch the original:

var draft = project.copy();
var report = draft.apply(changes);
if (report.needsResync) {
  // Drop `draft`. `project` still has its baseline; roll the edit back in your model too.
} else {
  draft.solve(null, new SolveOptions());
  project = draft;
}

Use this when the user should either get the whole change set or none of it.

Result#

The example prints the rejected removal on stderr and the refreshed date of every task on stdout:

rejected tasks.remove[0]: unknown task id
design 2026-01-05 00:00..2026-01-09 00:00

After the resync, apply, solve(null, …), level and preview work again, and report.needsResync is false for the next valid change set.