Skip to content

ZenNotes 2.66.0 - #917

Merged
adibhanna merged 4 commits into
mainfrom
v2.66.0
Oct 9, 2026
Merged

adibhanna merged 4 commits into
mainfrom
v2.66.0

Conversation

@adibhanna

Copy link
Copy Markdown
Contributor

ZenNotes 2.66.0.

Features

  • Published notes can carry up to 50 attachments and 100 MB (each file up to 10 MB), up from 20 and 25 MB. Attachments are staged straight to storage before the publish (website e94851c): publishWithStagedUploads in 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 with upload_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

  • The app's attachment check (50) and the service (20 for one-request publishes) now agree on 50.

Tooling

  • The smoke suites open their window on a Mac's built-in display when there is one.

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=high clean (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, bundled zn v0.6.3 in Resources/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.

…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))
@adibhanna
adibhanna merged commit 461fe76 into main Oct 9, 2026
9 checks passed
@adibhanna
adibhanna deleted the v2.66.0 branch October 9, 2026 21:25
@adibhanna
adibhanna restored the v2.66.0 branch October 9, 2026 21:25
@adibhanna
adibhanna deployed to boundary-artifacts October 9, 2026 21:30 — with GitHub Actions Active
@adibhanna
adibhanna deployed to boundary-artifacts October 9, 2026 21:31 — with GitHub Actions Active
@adibhanna
adibhanna deployed to boundary-artifacts October 9, 2026 21:35 — with GitHub Actions Active

This branch was successfully deployed

1 active deployment
boundary-artifacts — 461fe76d Deployed Oct 9, 2026 by adibhanna via draft #42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants