Delete methods should return last known state data

[stack72]

Problem

When a model's delete method succeeds, the response contains only metadata (modelId, modelName, type, methodName) — no data field. This is true even though the type schema defines dataOutputSpecs for the delete method with a state spec.

After a delete, there's no programmatic way to confirm what was removed. This matters for automation and audit logging where you want to record "deleted volume 8290fa55" or "deleted SSH key 54622838".

Observed behavior

{
  "modelId": "ca9547ff-...",
  "modelName": "test-volume",
  "type": "@stack72/digitalocean/volume",
  "methodName": "delete"
}

Expected behavior

The delete response should include the last known state from local data, e.g.:

{
  "modelId": "ca9547ff-...",
  "modelName": "test-volume",
  "type": "@stack72/digitalocean/volume",
  "methodName": "delete",
  "data": {
    "attributes": { "id": "8290fa55-...", "name": "swamp-crud-test-vol", ... }
  }
}

Proposed solution

Since the upstream API typically returns 204 No Content for deletes, swamp core should attach the last known state from its local data store as the delete response data. The data already exists locally from prior create/get/update calls — it just needs to be included in the delete response.

Scope

This is a swamp core issue, not provider-specific. The dataOutputSpecs are already defined on delete methods, suggesting the intent was to return data. Changes would be in the method execution path where delete responses are assembled.

Reproduction

Tested across 6 DigitalOcean model types (tag, ssh-key, project, vpc, volume, domain) — all delete methods return no data.

[stack72]

Additional findings: Delete tombstones break idempotent workflow re-runs

We hit this issue while building a production VPC delete workflow with 21 AWS resources across 4 jobs. The current delete behavior makes workflows non-idempotent — a partial failure means re-runs can't construct identifiers for already-deleted resources.

The problem in practice

Delete workflows construct resource identifiers from stored data via CEL expressions:

- name: delete-public-route
  task:
    type: model_method
    modelIdOrName: prod-public-route
    methodName: delete
    inputs:
      identifier: ${{ data.latest("prod-public-route", "public-route").attributes.RouteTableId + "|" + data.latest("prod-public-route", "public-route").attributes.CidrBlock }}

After the delete succeeds, the model writes a tombstone to the same data name (public-route) with only:

{
  "identifier": "rtb-xxx|0.0.0.0/0",
  "existed": true,
  "status": "deleted",
  "deletedAt": "2026-03-08T..."
}

This overwrites the original data that had RouteTableId, CidrBlock, GatewayId, etc. On a re-run, data.latest().attributes.RouteTableId fails:

Invalid expression: No such key: RouteTableId

>    1 | data.latest("prod-public-route", "public-route").attributes.RouteTableId
                                                                     ^

Why this matters

Complex infrastructure workflows are the most likely to have partial failures (API rate limits, dependency ordering issues, transient errors). A 4-job VPC delete with 21 resources will fail partway through during development. Without idempotent re-runs, the only workaround is adding allowFailure: true to every step and completed conditions on every job dependency — which masks real errors and produces noisy output.

Proposed solution alignment

If delete preserved the last known state (as proposed in this issue), the tombstone would contain the original attributes alongside the delete metadata. Re-runs would resolve CEL expressions successfully, see the resource is already deleted, and either skip or handle it gracefully.