Skip to main content
← Back to list
01Issue
BugShippedSwamp CLI
Assigneesstack72

Relationships

#1335 data query and data get return the same payload under different keys

Opened by ehazlett · 7/22/2026· Shipped 7/22/2026

The same data record exposes its payload under attributes in swamp data query, but under content in swamp data get.

Tested with:

swamp 20260722.020746.0-sha.5d00afa2

Querying an inventory resource:

swamp data query 'modelType == "@example/system/info"' --json

Returns a result shaped like:

{
  "results": [
    {
      "id": "record-id",
      "name": "worker-01",
      "attributes": {
        "hostname": "worker-01",
        "os": "linux",
        "arch": "x86_64"
      },
      "content": ""
    }
  ]
}

Fetching the same record directly:

swamp data get host-inventory worker-01 --json

Returns:

{
  "id": "record-id",
  "name": "worker-01",
  "content": {
    "hostname": "worker-01",
    "os": "linux",
    "arch": "x86_64"
  }
}

The problematic part is not only that the payload moves between keys. Query results also contain a content key with an empty-string value.

A client that reads content consistently across both commands receives no error from the query result. It silently interprets a populated record as having no payload.

Expected behavior

Preferably, both commands should expose the resource payload under content.

If attributes is intentionally an indexed or projected query representation, query results should omit content rather than returning an empty value. The distinction should also be documented clearly so clients can select the correct representation.

A typed discriminator or separate metadata field could further prevent clients from treating the empty content value as the resource payload.

Impact

Clients cannot safely use one record representation across search and retrieval operations.

Because content exists in query results, ordinary presence checks succeed while the actual payload is missed. This produces incomplete data without an exception, validation error, or other indication that the client used the wrong field.

02Bog Flow
OPENTRIAGEDIN PROGRESSSHIPPED+ 1 MOREASSIGNED+ 4 MOREREVIEW+ 4 MOREPR_MERGED+ 1 MORECONTRIBUTOR_NOTIFIED

Shipped

7/22/2026, 7:47:49 PM

Click a lifecycle step above to view its details.

03Sludge Pulse
stack72 assigned stack727/22/2026, 5:33:41 PM
Editable. Press Enter to edit.

stack72 commented 7/22/2026, 7:47:58 PM

Thanks @ehazlett for reporting this! The fix has been merged and a release is on its way. We appreciate your contribution to swamp.

Sign in to post a ripple.