Skip to content

cluster update --depends-on replaces rather than appends, silently dropping earlier edges #675

Description

@samuelcollins1

Problem

desloppify plan cluster update <name> --depends-on <other> persists only the last value written. Calling it a second time to add a second dependency replaces the first edge instead of appending, with no warning.

How it bit

A triage organize stage needed 21 dependency edges across 19 clusters. Several clusters legitimately depend on more than one predecessor. After writing them, only 13 edges were present in plan.json — the rest had been overwritten by subsequent calls to the same cluster. The 8 lost edges had to be recorded as prose "SEQUENCING" sentences inside cluster descriptions instead, where nothing can enforce or traverse them.

This matters because the ordering guarantees are the point of the field: a dropped edge means the queue can hand an executor a cluster whose prerequisite has not landed, and the tool cannot detect it.

Expected

Either append (so repeated calls accumulate), or accept a list in one call and document that it is a full replacement, or warn when an existing non-empty depends_on is being overwritten. Any of the three would prevent silent loss.

Repro

desloppify plan cluster update my-cluster --depends-on cluster-a
desloppify plan cluster update my-cluster --depends-on cluster-b
python3 -c "import json; print(json.load(open('.desloppify/plan.json'))['clusters']['my-cluster'].get('depends_on'))"
# shows only cluster-b

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions