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
- Verify the blob UUID exists (re-fetch the store/connection entry that references it) before requesting the stream.
- Re-upload/re-save the blob content if it was deleted, then use the newly returned UUID.
- Confirm the request goes to the same daemon instance that originally stored the blob.
- 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
- Regenerate blob ids after blob cleanup or storage resets
- Store blob data alongside the id in the same configuration source
- Never reuse blob UUIDs exported from another machine
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
- No active shell session known for id " + uuid
- Parent category with id " + msg.getParent() + " does not exi
- Couldn't send request
- Couldn't parse response
- Couldn't parse client error message
AI-assisted analysis of xpipe-io/xpipe@d85ca821ba (2026-09-06).
Data as JSON: /api/errors/03166bd434340a4f.
Report an issue: GitHub.