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(documents): a PDF added to a workflow never loaded
Three separate defects sat between picking a PDF and reading its bytes.
Every document node hand-rolled its own resolver: `resolvePdfBuffer` and
its siblings understood inline `data`, one exact storage key, and a local
path, then fell through to `fs.readFile(uri)`. An `asset://` ref, an https
signed URL (S3/Supabase), a `data:` URI or a `package://` example asset
died with a raw ENOENT. They now share `resolveDocumentBytes`, which
delegates to the runtime's `loadMediaRefBytes` — the resolver every other
media node already used.
`FileStorageAdapter.list()` in the runtime returned nothing unless called
with `delimiter: "/"`, which is not how `resolveAssetBytes` calls it. Its
extension-tolerant lookup (`asset://<id>` -> `<id>.pdf` on disk) therefore
always missed in CLI and DSL contexts. It now walks recursively, matching
the storage package's adapter.
`assets.createUpload` required a non-empty `parent_id`, but the property
dropzones upload with no folder — so every pick 400'd and the value never
reached the property. An empty parent now files under the caller's root,
as `POST /api/assets/` has always done.
Also: a graph opened before the node registry finished loading recorded
every one of its types as unknown, and that append-only set is spread over
the real node types — so known nodes kept rendering as "Missing Node" for
the rest of the session.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
0 commit comments