Repository navigation
Conversation
…raight to storage
Publishing sent a note and all its attachments in one request, and the
service's PHP drops every file past the 20th, so a published note was
capped at 20 attachments and 25 MB (website 6d5c638). On the way there,
every attachment was read as base64 in the renderer and crossed IPC
twice, so a large note sat in memory several times over.
The apps now stage attachments first (website e94851c). The renderer
hands each attachment to the platform by its vault-relative path
(CloudPublishAssetInput.path; no bytes cross the bridge). A shared
routine, publishWithStagedUploads in shared-domain, does the rest the
same way on every platform: it describes each file (size and SHA-256),
asks the service to start an upload, which checks the count (50), the
note's total (100 MB), each file's size and type and the account's room
before a byte is sent, PUTs every file to its presigned URL, four at a
time, then publishes naming the upload. A service that answers 404 for
uploads gets the old one-request publish, so a new app still publishes
where the switch is off. A failure after the upload starts cancels it.
On the desktop, main resolves each path through the vault's traversal
guard (or fetches it from a remote vault), hashes it as it streams off
the disk and streams it again into the PUT, with the safeguards of a
sync upload: HTTPS (loopback excepted), no redirects, no bearer token,
and an explicit Content-Length (object storage refuses a chunked PUT,
411) from a file that must still be the declared size.
The app's own count check follows: 50, with the service's wording
("This note has 51 attached files, but a published note can have at
most 50."). prepareCloudPublishLogo is gone: nothing called it, and the
logo is set for the whole publication in ZenNotes Cloud. A logo change
would still go the one-request way.
Tests: the shared routine (staging, republish, the 404 fallback, a
refusal that must not fall back, cancelling on a failed file or
publish, logo and empty notes, bounded concurrency), the request bodies,
the desktop client's PUT (length, type, no token, size mismatch, HTTP
refused, a 403), the service wiring from a file on disk, and over real
loopback HTTP the whole staged publish and republish plus the fallback.
…ilds The plan behind 1c05780 and website e94851c: why a published note was capped at 20 attachments, the stage-then-publish flow, why not literal batches of 20, and the three decisions made with Adib on October 9 (50 attachments, 100 MB per note, no logo in the publish). Its status banner says what shipped and what is still design: progress in the publish dialog, and reusing unchanged attachments on republish.
The three smoke suites opened their window at a fixed point on the main screen, which on a MacBook driving an external monitor is the desk's display, in the way of whatever is open there. testWindowState() puts it on the built-in display when there is one (found with NSScreen through JXA) and keeps the old spot everywhere else, CI included. All three suites passed with it on the 2.66.0 build.
| response.end() | ||
| } catch (error) { | ||
| response.writeHead(500) | ||
| response.end(String(error)) |
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ZenNotes 2.66.0.
Features
e94851c):publishWithStagedUploadsin shared-domain describes each file (size, SHA-256), starts an upload that checks every limit before a byte is sent, PUTs each file to its presigned URL four at a time, then publishes withupload_id. A 404 from the upload endpoint falls back to the one-request publish. Desktop main streams each file from disk (vault traversal guard, HTTPS or loopback, no redirects, no bearer token, explicit Content-Length); no attachment bytes cross IPC.Fixes
Tooling
Cycle verification: the service suite (1,263 tests, 21 new) and a live production run as the QA account with the switch on (a 30-image note staged, uploaded to R2 and published with every file verified; republish, cancel, unpublish clean). App side: the shared routine's tests, the desktop client's PUT, and over real loopback HTTP the desktop's whole staged publish and republish plus the fallback.
Local gates on
461fe76d: typecheck 8/8 and test:run 6/6 with no turbo cache (shared-domain 1,929, app-core 3,140, quicklook 15, desktop 1,059),npm audit --omit=dev --audit-level=highclean (15 low or moderate remain in dompurify, fast-uri, ip-address, katex, smol-toml and sprintf-js).npm run pack: build:prod green; codesign lost its timestamp once on this Mac (the TSA probe passed a minute later), so the pack finished against Apple's timestamp server by its IPv4 address; deep strict codesign OK, "skipped macOS notarization" next to the hook, bundledzn v0.6.3inResources/zn-cli(drwxr-xr-x); packaged launch check: page target in 1.6 s reporting 2.66.0. Smoke suites: vim-editor, sidebar-vim and editor-improvements passed on their first run.