Image loaded into a node is zeroed on disk, including a file already in {inputs}

[griptapeops]

Problem

Loading an image from outside the workspace into a LoadImage node produces a 0-byte file in {inputs}, and the image renders broken. Re-evaluating the node truncates a previously-good file back to 0 bytes.

Expected: the external file is copied into {inputs} intact, and an existing file with the same name is never clobbered — the copy_external_file situation declares CREATE_NEW, so a second load should allocate name_001.png.

Origin

Reported by Jason Schleifer on main. Reproducible: pick any image from a directory outside the workspace in LoadImage. The source file is valid (confirmed intact PNG); the emptiness is introduced on our side.

Impact

Loading external images — the common first step in most workflows — silently produces empty files. Worse, a file the user copied into {inputs} by hand gets destroyed the next time the node evaluates, so the manual workaround doesn't hold.

Repro / evidence

1. Put an image outside the workspace.
2. In LoadImage, browse to it and select it.
3. The preview is broken and {inputs}/images/<name>.png is 0 bytes.
4. Copy the image into {inputs} manually, select it, then evaluate the node — it is truncated to 0 bytes again.

Warning logged during the copy:

WARNING  Attempted to identify the format of bytes destined for '/Users/<user>/.../GriptapeNodes/inputs/images/<name>.png'.
         Could not recognize the bytes as a known file format, so the file will be written with its requested '.png'
         extension unchanged.

Two things line up with the symptoms:

• LocalStorageDriver.create_signed_upload_url writes an empty placeholder (content=b"", local_storage_driver.py) to claim the destination before handing out the PUT url. That empty write is what the format sniffer is complaining about — the bytes it is asked to identify are the placeholder's, not the image's. So the warning fires on the normal path and is misleading.
• on_handle_create_static_file_upload_url_request (static_files_manager.py) calls create_signed_upload_url(resolved.path, file_metadata=resolved.file_metadata) and does not pass resolved.policy, so the call takes the parameter default ExistingFilePolicy.OVERWRITE instead of the CREATE_NEW the situation declares. save_static_file threads the resolved policy through; this path does not.

That accounts for the broken first render (the display url is served while only the placeholder exists), the re-zeroing on evaluate (a second upload-url request overwrites the good file with the placeholder rather than allocating an indexed name), and why a manual copy alone works (no upload-url request, so no placeholder).

No unit test covers the manager's upload-url path passing the resolved policy through — tests/unit/drivers/storage/test_base_storage_driver.py covers the driver-level pass-through only.

[griptapeops]

More severe variant of the same root cause: a file that is already inside {inputs} gets zeroed on pick, before the node is ever evaluated.

Repro

1. Create a new workflow (leave it unsaved).
2. Add a LoadImage node.
3. Pick an image at {inputs}/images/<name>.jpg that has data.
4. The node renders a preview — and the original on disk is immediately 0 bytes.
5. Run the node:

RuntimeError: Image verification failed - cannot load image: Failed to load image from:
<workspace>/inputs/images/<name>.jpg
Error: cannot identify image file <_io.BytesIO object at 0x...>

Why being already in {inputs} makes it worse, not better

The node's picker is a plain <input type="file">. It yields a File blob and file.name — no path — so the GUI unconditionally routes through uploadStaticFile(preview, file.name). It has no way to know the picked file already lives in the workspace, so picking {inputs}/images/<name>.jpg takes the identical copy_external_file path as a file from outside the workspace.

The copy_external_file macro is {inputs}/{node_name?:_}{parameter_name?:_}{file_name_base}{_index?:03}.{file_extension}, and with the optional tokens absent it resolves to exactly the file that was picked. Combined with the dropped resolved.policy already described above, create_signed_upload_url takes the default OVERWRITE and writes content=b"" straight onto the user's original.

So destination == source, and the placeholder write is the destructive write. With the CREATE_NEW the situation declares, it would have resolved to <name>_001.jpg and never touched the original.

In the external-file case the file survives only because destination ≠ source — the PUT lands on a fresh path. Here there is nothing to restore from.

An unsaved workflow guarantees the collision

The log shows the {inputs} directory macro losing its leading segment:

WARNING  Optional builtin 'workflow_dir' could not be resolved while resolving directory 'inputs';
         dropping it from the path (Workflow 'unsaved:<id>' has not been saved yet)

DEFAULT_PROJECT_TEMPLATE_V1 defines inputs as {workflow_dir?:/}inputs. Until the workflow is saved there is no workflow_dir, so it drops to workspace-level inputs/ — the same directory the user browsed. A saved workflow would resolve to a per-workflow subdirectory and dodge the collision by accident, which is likely why this variant is intermittent.

The failed write is also silent

uploadStaticFile never checks the PUT response — no .ok, no catch. If the upload fails the GUI still fetches the display URL and sets the parameter, so a 0-byte file presents as a successfully loaded image. The log is consistent with exactly one placeholder write and no successful restore: a single sniff warning, then Resolving Load Image ~9s later failing on empty bytes. Why the PUT did not land is still open.

Not a regression

Reported as new on main and not observed in the packaged app on either stable or nightly, so I checked whether recent work introduced it. It did not:

• latest (the nightly channel) and main are currently the same commit.
• git diff stable..main across drivers/storage/, servers/, static_files_manager.py, os_manager.py, and project_templates/ is empty.
• The dropped-policy call site dates to fix: route file uploads through copy_external_file situation #4210 (March, v0.78.0). Template V1's {workflow_dir?:/}inputs landed in Update/default project template #4999 (July, v0.92.0). Both are in stable.
• load_image.py is identical across the library's stable, nightly, and main.

So a second engine process is not needed to explain it either — the destructive write happens in the engine that serves the upload-url request, not across processes. The channel difference is more likely environmental: the reporter runs against a workspace of unsaved workflows and a local monorepo library checkout, and {inputs} collapsing to the workspace root on an unsaved workflow is what makes destination and source coincide.

Three stacked defects, in severity order: the dropped policy (destructive), the picker's inability to recognize an in-workspace file (makes the collision certain), and the unchecked upload response (hides the failure).

Reported by Jason Schleifer.

[griptapeops]

Reported by Jason Schleifer: the failure tracks the engine, not the editor or the workspace config.

Editor	Engine	Result
Desktop app	app-bundled engine	works
Desktop app	local main	fails
localhost:5173	local main	fails
Hosted editor	local main	fails

Three different editors fail against local main, and the only passing config is the app's own bundled engine. That rules out the editor build and rules out the reporter's workspace/project config, both of which I had previously suspected. It also rules out a second engine racing the write: the destructive b"" write happens inside whichever engine serves the upload-URL request, before any PUT.

What I could not confirm is a regression in engine source on this path. Specifically:

• The app pins griptape-nodes-engine>=0.101.0, and 0.101.0 is the newest published engine, so a stable app build and a local main differ by the v0.101.0..main range.
• Across that range nothing touches the storage drivers, static_files_manager, the project templates, or os_manager's write path — the six commits are an element-module split, two execution/deletion fixes, and docs.
• The two defective lines are older than every channel involved: the dropped resolved.policy at the create_signed_upload_url call site, and the content=b"" placeholder write in LocalStorageDriver. Both are present in 0.101.0 and in the app-bundled engine.

So the mechanism is confirmed and version-independent, but "why the bundled engine survives it" is still open. The difference is most likely in what the bundled engine resolves at build time rather than in engine source on this path — the bundle installs from PyPI under a constraints file, so its dependency set is not identical to a uv sync of main. Worth checking a dependency that affects the write path before assuming engine source.

Regardless of which channel exposes it, the destructive part stands on its own and is worth fixing directly: create_signed_upload_url should refuse to truncate when the resolved destination is the file being read, independent of the policy fix.

[griptapeops]

Reproduced deterministically outside the GUI, and it is not a regression

I had been diffing branches and releases to find a recent change. That was the wrong approach — I executed the write path directly instead, and it reproduces with no GUI, no static server, and no browser involved.

Driving OSManager.on_write_file_request with the same arguments LocalStorageDriver.create_signed_upload_url uses (content=b"", skip_metadata_injection=True) against a file that already exists at the resolved destination:

policy=OVERWRITE    ok=True before=68 AFTER_SRC=0   final=<workspace>/inputs/images/<name>.png
policy=CREATE_NEW   ok=True before=68 AFTER_SRC=68  final=<workspace>/inputs/images/<name>_1.png

OVERWRITE truncates the existing file to 0 bytes and returns success. It also emits the exact warning from the report, because the sniffer is inspecting the empty placeholder rather than any real image:

Attempted to identify the format of bytes destined for '<path>.png'. Could not recognize the
bytes as a known file format, so the file will be written with its requested '.png' extension unchanged.

With CREATE_NEW the original survives and the placeholder is allocated a new name. So the destructive behavior is entirely decided by which policy reaches the driver.

Why the wrong policy reaches it

static_files_manager.py:264 calls:

response = self.storage_driver.create_signed_upload_url(resolved.path, file_metadata=resolved.file_metadata)

resolved.policy is not passed, so the call takes the parameter default ExistingFilePolicy.OVERWRITE. save_static_file does thread its policy through (:551-554); this path does not.

The policy that should arrive is CREATE_NEW. Verified by resolving it rather than reading it — for both template majors:

major=0 on_collision=create_new -> ExistingFilePolicy.CREATE_NEW
major=1 on_collision=create_new -> ExistingFilePolicy.CREATE_NEW

Not a regression, and not template-major dependent

Two earlier theories on this issue should be disregarded; I verified both are wrong:

• Not recent. The same script produces byte-identical output on released engines 0.98.0, 0.99.0, 0.101.0, and current main. Comparing the installed 0.101.0 package tree against main shows only 10 differing files — node_executor.py, core_types.py, the new exe_types/elements split, node_types.py, dag_builder.py, parallel_resolution.py, workflow_events.py, and the flow/node/workflow managers. All are the element-module split and the node-deletion-during-run fixes. Nothing touches the storage drivers, static_files_manager, os_manager's write path, or the project templates.
• Not the V0-vs-V1 template. Both majors declare CREATE_NEW for copy_external_file, so neither is protected by its policy. The macros do differ in where they route ({inputs}/... vs {inputs}/{file_extension_directory?:/}...), which changes whether the destination collides with the picked file, but not what happens when it does.

Since the truncation happens before any PUT, a second engine process is not required to explain it either.

Consequence

Any upload-URL request whose resolved destination is an existing file zeroes that file immediately, and reports success. When the user picks a file that already lives in the directory the situation resolves to, the destination is the source, so the placeholder write destroys the original — a file the user never asked to have copied.

Two defects worth separating:

1. The dropped resolved.policy at :264.
2. create_signed_upload_url is willing to truncate in place at all. Even with the policy fixed, claiming a destination by writing b"" over existing content is destructive by construction. Worth refusing when the resolved destination already exists and is non-empty, independent of policy.

Reported by Jason Schneider.

[griptapeops]

Found the specific mechanism, verified by running the real engine (no GUI, no browser). The destructive write is ordered before the two steps that can fail, so whenever either fails the file is already gone and nothing restores it.

The order of operations in create_signed_upload_url

LocalStorageDriver.create_signed_upload_url does three things in this order:

1. Write content=b"" to the resolved destination to claim it (local_storage_driver.py:71-84).
2. POST /static-upload-urls to the static server to mint the PUT url (:94).
3. Return the url so the caller can PUT the real bytes.

Step 1 is destructive and irreversible. Steps 2 and 3 are both failure points. If either fails, or if the PUT that follows goes somewhere other than the file truncated in step 1, the user's file stays at 0 bytes.

Why it looked unreproducible

The happy path self-heals, which is why this only shows up in some configurations. Driving CreateStaticFileUploadUrlRequest + PUT against a healthy self-hosted server:

upload url: http://localhost:<port>/static-uploads/inputs/images/pic.png
src after url request: 0
PUT -> 200
src after PUT: 127      <- restored

Repeated three times, it truncates and restores each time. So a passing config is not evidence the bug is absent — only that step 2 and the PUT both succeeded.

Two verified ways the restore misses

Host-provided server pointing at a different workspace. AppInitializationComplete.static_server_base_url makes the engine advertise a server it does not run (static_files_manager.py:465-470). The placeholder is written by this engine into its workspace; the PUT goes to the other server, which resolves the same relative path against its own workspace_path (servers/static.py:63-64):

advertised base:  http://localhost:8124
src after url request: 0
PUT -> 200
src AFTER PUT: 0            <- user's file, still empty
other engine's workspace:  127   <- bytes landed here

The PUT returns 200. Nothing is logged as wrong.

Configured static_server_base_url plus a port fallback. bind_free_socket silently falls back to an OS-assigned port when the configured port is taken (servers/__init__.py:17-20), but a configured base url is advertised verbatim (static_files_manager.py:494-496). So the engine serves on the fallback port and advertises the configured one. Same result: 200, bytes land in whatever is listening there, user's file stays 0.

And the plain failure case — when step 2 itself fails, the file is already truncated:

src before: 128
RESULT: CreateStaticFileUploadUrlResultFailure
details: Failed to create presigned URL ... Connection refused
src AFTER failed request: 0

The request correctly reports failure, and the file is destroyed anyway.

Notes on earlier comments in this issue

• The sniff warning is the placeholder being inspected, not the user's image. Cosmetic.
• The dropped resolved.policy at static_files_manager.py:264 is real and worth fixing — CREATE_NEW would route the placeholder to name_1.png and never touch an existing file. But it is not what distinguishes a working config from a broken one; both resolve the same way.
• Preview generation is not implicated. preview=True and metadata_only=True on CreateStaticFileDownloadUrlFromPathRequest both leave the source byte-identical when tested.
• CORS is not implicated; preflight returns 200 with a correct allow-origin for the app, localhost:5173, and the desktop origin.

Possible direction

Claiming a destination by destroying what is there, before the steps that can fail, is the root problem. Writing the placeholder to a temp path and moving it into place only once the upload url exists — or not pre-writing at all and resolving the name without touching the filesystem — would make every one of the above harmless. Separately, advertising a base url the engine does not serve on is worth surfacing rather than failing silently with a 200.

Reported by Jason.

[shhlife]

I think this may have to do with having multiple engines running..