What happened
The fd-pinned filesystem writer ignores FileHandle.write()'s bytesWritten result. A successful short write therefore silently truncates the requested content while the filesystem worker reports ok: true and the full requested byte count.
On current main, a real 4,096-byte Write with a 1,024-byte process file-size limit returned success and bytes: 4096, but the file contained only 1,024 bytes. No filesystem mocks were used in this reproduction.
Expected: continue writing the remaining bytes through the same descriptor. If a subsequent write fails or makes no progress, report the existing outcome_unknown result so the caller knows it must re-read the file.
How to reproduce
Build the repository, then run this POSIX-only probe from its root (Python supplies the process resource limit; Node runs the production writer):
import os, resource, signal, subprocess, tempfile
script = """
import { open, stat } from 'node:fs/promises';
import { writeThroughHandle } from './packages/runtime/dist/file-stable-write.js';
const file = process.argv[1];
const handle = await open(file, 'w+');
try {
await writeThroughHandle(handle, 'x'.repeat(4096));
console.log('write reported success');
} finally {
await handle.close();
}
console.log('actual bytes:', (await stat(file)).size);
"""
def limit_file_size():
signal.signal(signal.SIGXFSZ, signal.SIG_IGN)
resource.setrlimit(resource.RLIMIT_FSIZE, (1024, 1024))
with tempfile.TemporaryDirectory() as directory:
subprocess.run(
['node', '--input-type=module', '-e', script, os.path.join(directory, 'file.txt')],
preexec_fn=limit_file_size, check=True,
)
Actual output: write reported success, actual bytes: 1024.
A separate probe through executeFilesystemWorkerRequest confirms the same false-success response in the production Write operation, rather than only in the helper.
Environment
- Maka commit:
27add3049
- macOS arm64
- Node 24.18.1; helper also reproduced on Node 26.4.0
- Surface: Runtime filesystem worker (shared fd-pinned Write/Edit/ApplyPatch/FormatJson helper)
Logs, screenshots, or additional context
packages/runtime/src/file-stable-write.ts:166 truncates the descriptor, performs one string write, and discards its result. File identity verification after the write cannot detect an incomplete payload on the same inode.
The fix must preserve explicit byte positions after a prior readFile, UTF-8 boundaries across short writes, and the existing path-identity protections. Searching existing issues/PRs found no matching short-write fix. Open PR #4542 touches an unrelated comment in this file.
Automated report: OpenAI Codex reproduced and documented this issue as part of the contributor's requested audit.
What happened
The fd-pinned filesystem writer ignores
FileHandle.write()'sbytesWrittenresult. A successful short write therefore silently truncates the requested content while the filesystem worker reportsok: trueand the full requested byte count.On current main, a real 4,096-byte Write with a 1,024-byte process file-size limit returned success and
bytes: 4096, but the file contained only 1,024 bytes. No filesystem mocks were used in this reproduction.Expected: continue writing the remaining bytes through the same descriptor. If a subsequent write fails or makes no progress, report the existing
outcome_unknownresult so the caller knows it must re-read the file.How to reproduce
Build the repository, then run this POSIX-only probe from its root (Python supplies the process resource limit; Node runs the production writer):
Actual output:
write reported success,actual bytes: 1024.A separate probe through
executeFilesystemWorkerRequestconfirms the same false-success response in the production Write operation, rather than only in the helper.Environment
27add3049Logs, screenshots, or additional context
packages/runtime/src/file-stable-write.ts:166truncates the descriptor, performs one string write, and discards its result. File identity verification after the write cannot detect an incomplete payload on the same inode.The fix must preserve explicit byte positions after a prior
readFile, UTF-8 boundaries across short writes, and the existing path-identity protections. Searching existing issues/PRs found no matching short-write fix. Open PR #4542 touches an unrelated comment in this file.Automated report: OpenAI Codex reproduced and documented this issue as part of the contributor's requested audit.