xpipe-io/xpipe · error · BeaconClientException

No saved data known for id " + uuid

Error message

No saved data known for id " + uuid

What it means

BlobManager serves saved binary blobs either from an in-memory cache or from files on disk keyed by UUID. getBlob throws BeaconClientException when no blob with the requested UUID is registered in fileBlobs (and it wasn't in memory), i.e. the referenced saved data does not exist on this daemon.

Source

Thrown at app/src/main/java/io/xpipe/app/beacon/BlobManager.java:84

    }

    public void store(UUID uuid, InputStream blob) throws IOException {
        var file = TEMP.resolve(uuid.toString());
        try (var fileOut = Files.newOutputStream(file)) {
            blob.transferTo(fileOut);
        }
        fileBlobs.put(uuid, file);
    }

    public InputStream getBlob(UUID uuid) throws Exception {
        var memory = memoryBlobs.get(uuid);
        if (memory != null) {
            return new ByteArrayInputStream(memory);
        }

        var found = fileBlobs.get(uuid);
        if (found == null) {
            throw new BeaconClientException("No saved data known for id " + uuid);
        }

        return Files.newInputStream(found);
    }
}

View on GitHub (pinned to d85ca821ba)

Solutions

  1. Verify the blob UUID exists (re-fetch the store/connection entry that references it) before requesting the stream.
  2. Re-upload/re-save the blob content if it was deleted, then use the newly returned UUID.
  3. Confirm the request goes to the same daemon instance that originally stored the blob.
  4. Handle the BeaconClientException by treating the blob as missing and regenerating it rather than crashing.

Example fix

// before
InputStream in = blobManager.getBlob(savedUuid); // throws if purged
// after
UUID id = savedUuid;
try {
    InputStream in = blobManager.getBlob(id);
} catch (BeaconClientException e) {
    id = reuploadBlob(originalData); // recreate and persist new id
    InputStream in = blobManager.getBlob(id);
}
Defensive patterns

Strategy: validation

Validate before calling

// confirm the blob id is referenced by a current store entry
boolean blobKnown = storeEntry.getData().getUuids().contains(uuid);

Type guard

boolean isKnownBlob(UUID uuid, Map<UUID, Path> fileBlobs) {
    return uuid != null && fileBlobs.containsKey(uuid);
}

Try / catch

try {
    return blobManager.getBlob(uuid);
} catch (BeaconClientException e) {
    return reuploadAndReturnStream(originalData); // regenerate missing blob
}

Prevention

When it happens

Trigger: Requesting a blob UUID that was never stored, was deleted (blob cleanup / config removal), belongs to a different daemon instance, or was mistyped; reading a blob after the underlying store entry was removed.

Common situations: Automation reusing blob ids saved in an old config; blobs purged by housekeeping; pointing a client at a fresh XPipe installation that lacks the original blobs.

Understand the failure class

Background: 'Could not be found', 'does not exist', 'not found in database': the resource-not-found family when an ID, slug, key, or URI lookup comes back empty — this error's family across 20 libraries.

Related errors


AI-assisted analysis of xpipe-io/xpipe@d85ca821ba (2026-09-06). Data as JSON: /api/errors/03166bd434340a4f. Report an issue: GitHub.