astrid-runtime/astrid · error
filesystem payload exceeds limit
Error message
filesystem payload exceeds limit
What it means
After decoding a Write payload, decode_operation_v2 checks its length against STORAGE_FILESYSTEM_MAX_IO_BYTES and rejects anything larger with this InvalidData error. This guards the kernel from a single callback frame demanding an oversized write I/O.
Solutions
- Split large writes into chunks of at most STORAGE_FILESYSTEM_MAX_IO_BYTES before issuing Write operations
- Check the file/blob size up front and use multiple sequential writes with offsets
- Raise STORAGE_FILESYSTEM_MAX_IO_BYTES if your workload legitimately needs bigger single I/Os and you control both ends
Example fix
// before
fs.write(path, 0, &huge_blob)?;
// after
for (i, chunk) in huge_blob.chunks(STORAGE_FILESYSTEM_MAX_IO_BYTES as usize).enumerate() {
fs.write(path, (i * STORAGE_FILESYSTEM_MAX_IO_BYTES as usize) as u64, chunk)?;
} Defensive patterns
Strategy: validation
Validate before calling
fn is_within_io_limit(data: &[u8]) -> bool {
(data.len() as u64) <= STORAGE_FILESYSTEM_MAX_IO_BYTES
}
assert!(is_within_io_limit(&data), "split writes to <= STORAGE_FILESYSTEM_MAX_IO_BYTES"); Try / catch
match result {
Err(e) if e.to_string() == "filesystem payload exceeds limit" => {
eprintln!("write too large: chunk into <= {} byte writes", STORAGE_FILESYSTEM_MAX_IO_BYTES);
}
other => other?,
} Prevention
- Check blob size before issuing a Write and chunk accordingly
- Keep a shared constant for max I/O size on both client and kernel
- Never assume the kernel will split oversized writes for you
When it happens
Trigger: A StorageFilesystemOperationV1::Write whose decoded data length (data.len() saturating to u64::MAX) exceeds STORAGE_FILESYSTEM_MAX_IO_BYTES is submitted over the mount callback socket.
Common situations: A filesystem client performs a very large buffered write that the FUSE layer passes through unsplit; a batch tool streams a multi-GB blob in one write call; a malicious/buggy peer sends a huge payload.
Understand the failure class
Background: payload too large / request exceeds maximum size: why libraries cap bytes and how to fix oversize payloads — this error's family across 50 libraries.
Related errors
- mount callback response exceeds limit
- environment value for
- FUSE service launch exceeds limit
- mount callback frame exceeds limit
- mount callback response is too large
AI-assisted analysis of astrid-runtime/astrid@affd8760f4 (2026-09-09).
Data as JSON: /api/errors/4aff61a9a69e72e0.
Report an issue: GitHub.
Appendix: source
Thrown at crates/astrid-kernel/src/storage_mount.rs:647
offset,
length,
},
StorageFilesystemOperationV2::Write {
path,
offset,
data_base64,
} => {
let data = base64::engine::general_purpose::STANDARD
.decode(data_base64.as_bytes())
.map_err(|error| {
io::Error::new(
io::ErrorKind::InvalidData,
format!("invalid base64 filesystem payload: {error}"),
)
})?;
let data_length = u64::try_from(data.len()).unwrap_or(u64::MAX);
if data_length > STORAGE_FILESYSTEM_MAX_IO_BYTES {
return Err(io::Error::new(
io::ErrorKind::InvalidData,
"filesystem payload exceeds limit",
));
}
StorageFilesystemOperationV1::Write { path, offset, data }
},
StorageFilesystemOperationV2::SetLength { path, length } => {
StorageFilesystemOperationV1::SetLength { path, length }
},
StorageFilesystemOperationV2::Create { path, kind } => {
StorageFilesystemOperationV1::Create { path, kind }
},
StorageFilesystemOperationV2::Remove { path } => {
StorageFilesystemOperationV1::Remove { path }
},
StorageFilesystemOperationV2::Rename { from, to, replace } => {
StorageFilesystemOperationV1::Rename { from, to, replace }
},View on GitHub (pinned to affd8760f4)