You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(execution): give each execution file a unique storage key
Execution file keys were built as
execution/{workspaceId}/{workflowId}/{executionId}/{fileName}, so two files
sharing a display name within one execution resolved to the same key and URL.
The second upload overwrote the first in object storage and updated its
workspace_files row instead of inserting, silently losing a file. Any trigger
that ingests multiple attachments hits this — repeated screenshot names, mail
clients that reuse inline-image names, or a loop emitting the same output name.
generateUniqueExecutionFileKey now allocates a unique directory segment
(.../{executionId}/{uuid}/{fileName}) and uploadExecutionFile uses it, so every
execution file gets its own key. The uniquifier is its own path segment rather
than a filename prefix because presigned URLs carry no content-disposition: the
key's final segment is the name a consumer sees, and a prefix would rename
every download.
The deterministic generator is renamed to generateLargeValuePayloadKey and
takes the payload id instead of a free-form file name, so no user-supplied name
can reach a key without a uniquifier. Its output is unchanged — determinism is
load-bearing there, since the cleanup job matches those keys by LIKE pattern
and the trace store recovers workflowId by segment position.
Every reader tolerates the extra segment: key parsers use parts.length >= 5
with fixed indices, storage providers write a preserved key verbatim, and
local-disk storage already creates the dirname recursively.
0 commit comments