Missing `added` deltas on startup

[MetRonnie]

This is somewhat difficult to reproduce, but sometimes when starting a workflow, I see missing added deltas. This causes cylc/cylc-ui#1922 as we only ever get updated deltas for the root family(s) at the first cycle point(s).

For example, in the delta below which I captured from the browser devtools network panel, the first delta that we receive in the UI that contains any data, has added: 3/root only, and updated: 1/root, 2/root, 3/root.

The full delta (with some extraneous details removed):

{
  "payload": {
    "data": {
      "deltas": {
        "added": {
          "familyProxies": [
            {
              "id": "~user/wflow//3/root",
              "state": "waiting",
              "ancestors": [],
              "childTasks": [{ "id": "~user/wflow//3/a" }]
            }
          ],
          "taskProxies": [
            {
              "id": "~user/wflow//3/a",
              "state": "waiting",
              "isHeld": false,
              "isQueued": false,
              "isRunahead": false,
              "isRetry": false,
              "isWallclock": false,
              "isXtriggered": false,
              "firstParent": { "id": "~user/wflow//3/root" },
              "runtime": { "runMode": "Simulation" },
              "flowNums": "[]",
            }
          ],
          "jobs": [],
        },
        "updated": {
          "workflow": { 
            "id": "~user/wflow",
          },
          "familyProxies": [
            {
              "id": "~user/wflow//1/root",
              "state": "succeeded",
              "childTasks": [{ "id": "~user/wflow//1/a" }]
            },
            {
              "id": "~user/wflow//3/root",
              "state": "waiting",
              "childTasks": [{ "id": "~user/wflow//3/a" }]
            },
            {
              "id": "~user/wflow//2/root",
              "state": "waiting",
              "childTasks": [{ "id": "~user/wflow//2/a" }]
            }
          ],
          "taskProxies": [
            {
              "id": "~user/wflow//1/a",
              "state": "succeeded",
              "firstParent": { "id": "~user/wflow//1/root" },
            },
            {
              "id": "~user/wflow//2/a",
              "state": "waiting",
              "isQueued": true,
              "isRunahead": false,
              "isRetry": false,
              "isWallclock": false,
              "isXtriggered": false,
              "firstParent": { "id": "~user/wflow//2/root" },
              "runtime": { "runMode": "Simulation" },
              "flowNums": "[1]",
            },
            {
              "id": "~user/wflow//3/a",
              "firstParent": { "id": "~user/wflow//3/root" },
            }
          ],
          "jobs": [
            {
              "id": "~user/wflow//1/a/01",
              "finishedTime": "2025-12-19T15:46:39Z",
              "state": "succeeded",
              "messages": ["started", "succeeded"],
              "taskProxy": {
                "outputs": [
                  { "label": "submitted", "message": "submitted" },
                  { "label": "started", "message": "started" },
                  { "label": "succeeded", "message": "succeeded" }
                ],
              },
            }
          ],
        },
        "pruned": {
          "familyProxies": [],
          "taskProxies": [],
          "jobs": [],
        },
        "id": "~user/wflow",
      }
    }
  }
}

Example workflow:

[scheduling]
    cycling mode = integer
    initial cycle point = 1
    [[graph]]
        P1 = a[-P1] => a

$ cylc clean wflow --rm .service:log && cylc play wflow --mode simulation

I seem to be able to reproduce this most of the time, on uiserver 1.8.1

However... it's very hard to reproduce since #761.

@dwsutherland Do you have any insight into whether #761 has fixed this entirely, or is it simply mitigating the chances of reproducing this?

[dwsutherland]

@dwsutherland Do you have any insight into whether #761 has fixed this entirely, or is it simply mitigating the chances of reproducing this?

If this was related to the empty workflow added delta, then yes.

If the empty added workflow delta came in after the initial dump added delta (or this never arrived?), then it could cause cylc/cylc-ui#1922 ..

Hard to say unless we had a way of reproducing the exact same problem.

[MetRonnie]

If this was related to the empty workflow added delta, then yes.

In that case, closing as fixed by #761