Summary
app:saveArtifactAs can delete an existing destination when the final replacement fails.
Reproduction
This was reproduced against the installed arm64 package Maka 0.2.0-dev.20.20260904 using the packaged Electron module (no user files or source changes). The disposable fixture starts with a destination containing ORIGINAL. The artifact is streamed completely to the staging file. The test then injects an EIO failure only for the final rename(stagingPath, targetPath).
Observed result:
before: { exists: true, content: "ORIGINAL" }
result: { ok: false, reason: "write_failed" }
after: { exists: false, error: "ENOENT" }
injectedRenameCalls: 1
The normal overwrite control case succeeds and writes the new content. Stream interruption and size mismatch cases preserve ORIGINAL.
Reproduction script and full output:
/Users/liugddx/code/output/maka-verification/reproduce-issues.mjs/Users/liugddx/code/output/maka-verification/conclusions.md
Suspected cause
In apps/desktop/src/main/runtime-host-artifacts-ipc-main.ts, materializeArtifact removes the destination before renaming the staging file:
await rm(targetPath, { force: true });
await rename(stagingPath, targetPath);If the rename fails, the catch block removes the staging file but does not restore or preserve the previous destination.
Expected behavior
If replacing an existing destination fails, the original destination should remain readable and unchanged.
Scope
This is a fault-injection reproduction of the final replacement step. It does not establish the frequency of real filesystem failures, and no user file was touched. The issue is data preservation during a failed overwrite, not a claim that normal exports always fail.
Environment
- macOS 13.4.1
- Apple Silicon / arm64
- Installed Maka
0.2.0-dev.20.20260904
Summary
app:saveArtifactAscan delete an existing destination when the final replacement fails.Reproduction
This was reproduced against the installed arm64 package
Maka 0.2.0-dev.20.20260904using the packaged Electron module (no user files or source changes). The disposable fixture starts with a destination containingORIGINAL. The artifact is streamed completely to the staging file. The test then injects anEIOfailure only for the finalrename(stagingPath, targetPath).Observed result:
The normal overwrite control case succeeds and writes the new content. Stream interruption and size mismatch cases preserve
ORIGINAL.Reproduction script and full output:
/Users/liugddx/code/output/maka-verification/reproduce-issues.mjs/Users/liugddx/code/output/maka-verification/conclusions.mdSuspected cause
In
apps/desktop/src/main/runtime-host-artifacts-ipc-main.ts,materializeArtifactremoves the destination before renaming the staging file:If the rename fails, the catch block removes the staging file but does not restore or preserve the previous destination.
Expected behavior
If replacing an existing destination fails, the original destination should remain readable and unchanged.
Scope
This is a fault-injection reproduction of the final replacement step. It does not establish the frequency of real filesystem failures, and no user file was touched. The issue is data preservation during a failed overwrite, not a claim that normal exports always fail.
Environment
0.2.0-dev.20.20260904