PERF: benchmark and optimise per-User WebDAV write serialisation (#457) with fsync (#429) #476

Open
opened 2026-09-30 04:46:10 +00:00 by kayg · 31 comments
Owner

Request (owner, 2026-09-30): "please benchmark this, we want to maximize performance"

#457 serialises each User's WebDAV writes (uploads included) so lock checks cannot race, and keeps locks in memory. Measure what that costs, then optimise.

  • Protocol: on the perf VM under flock /root/perf.lock, a release build, interleaved runs (serialised vs a build with the per-User write mutex removed) at N = 1, 4, 8 and 16 parallel PUTs of 1 KiB, 1 MiB and 64 MiB files, one User and then two Users. Report p50/p95 latency, throughput and CPU. Include Finder-like behaviour (LOCK, PUT, UNLOCK per file; .DS_Store and AppleDouble files) using the #457 litmus and the Mac capture.
  • Decision rule up front: if serialisation costs more than 10% throughput at N ≥ 4, replace the per-User mutex with a finer lock (per path or per lock token, checked atomically with the write) that keeps the #457 guarantees (a write without the token gets 423; no race). Prove it with a concurrency test and a rerun of the litmus locks suite.
  • Tie in #429 (per-file fsync cost): measure both together and report which dominates.
    Gates: per crate (calternal-dav, calternal-fs, calternal-server), the adversarial DAV round, and the numbers verbatim.
## Request (owner, 2026-09-30): "please benchmark this, we want to maximize performance" #457 serialises each User's WebDAV writes (uploads included) so lock checks cannot race, and keeps locks in memory. Measure what that costs, then optimise. - Protocol: on the perf VM under `flock /root/perf.lock`, a release build, interleaved runs (serialised vs a build with the per-User write mutex removed) at N = 1, 4, 8 and 16 parallel PUTs of 1 KiB, 1 MiB and 64 MiB files, one User and then two Users. Report p50/p95 latency, throughput and CPU. Include Finder-like behaviour (LOCK, PUT, UNLOCK per file; `.DS_Store` and AppleDouble files) using the #457 litmus and the Mac capture. - Decision rule up front: if serialisation costs more than 10% throughput at N ≥ 4, replace the per-User mutex with a finer lock (per path or per lock token, checked atomically with the write) that keeps the #457 guarantees (a write without the token gets 423; no race). Prove it with a concurrency test and a rerun of the litmus locks suite. - Tie in #429 (per-file fsync cost): measure both together and report which dominates. Gates: per crate (calternal-dav, calternal-fs, calternal-server), the adversarial DAV round, and the numbers verbatim.
Author
Owner

Starting #476 on branch job/webdav-lock-476. Initial HEAD/base SHA: cc25c441b7. I am checking current DAV lock semantics and building a repeatable concurrent PUT profile before narrowing the mutation gate.

Starting #476 on branch job/webdav-lock-476. Initial HEAD/base SHA: cc25c441b7a974185622a1dee853cf38686d2b67. I am checking current DAV lock semantics and building a repeatable concurrent PUT profile before narrowing the mutation gate.
Author
Owner

Baseline evidence from the isolated perf VM: the 8-way, 1 MB, same-folder, unlocked PUT burst completed at 8.57 MiB/s with p95 PUT latency 889.09 ms. The VM load average inside was 0.28 / 0.14 / 0.09. The first Finder-style lock burst did not produce a timing row: all 8 LOCK requests to new file URLs returned HTTP 403. No 5xx or data-loss result appeared. I am checking lock-null creation against existing-resource LOCK before treating this as a route defect.

Baseline evidence from the isolated perf VM: the 8-way, 1 MB, same-folder, unlocked PUT burst completed at 8.57 MiB/s with p95 PUT latency 889.09 ms. The VM load average inside was 0.28 / 0.14 / 0.09. The first Finder-style lock burst did not produce a timing row: all 8 LOCK requests to new file URLs returned HTTP 403. No 5xx or data-loss result appeared. I am checking lock-null creation against existing-resource LOCK before treating this as a route defect.
Author
Owner

Baseline evidence from the isolated perf VM: the 8-way, 1 MB, same-folder, unlocked PUT burst completed at 8.57 MiB/s with p95 PUT latency 889.09 ms. The VM load average inside the perf lock was 0.28 / 0.14 / 0.09. The first Finder-style lock burst did not produce a timing row: all 8 LOCK requests to new file URLs returned HTTP 403. No 5xx or data-loss result appeared. I am checking lock-null creation against existing-resource LOCK before treating this as a route defect.

Baseline evidence from the isolated perf VM: the 8-way, 1 MB, same-folder, unlocked PUT burst completed at 8.57 MiB/s with p95 PUT latency 889.09 ms. The VM load average inside the perf lock was 0.28 / 0.14 / 0.09. The first Finder-style lock burst did not produce a timing row: all 8 LOCK requests to new file URLs returned HTTP 403. No 5xx or data-loss result appeared. I am checking lock-null creation against existing-resource LOCK before treating this as a route defect.
Author
Owner

Baseline correction: the first perf service binary is not current enough for #476. Under the VM lock, OPTIONS returned HTTP 200 with DAV class 1 only, and Allow omitted LOCK and UNLOCK. The earlier 8-way unlocked PUT number is not a valid #476 baseline and will be discarded. I stopped that isolated server and will use a release build of the merged branch before recording the baseline matrix.

Baseline correction: the first perf service binary is not current enough for #476. Under the VM lock, OPTIONS returned HTTP 200 with DAV class 1 only, and Allow omitted LOCK and UNLOCK. The earlier 8-way unlocked PUT number is not a valid #476 baseline and will be discarded. I stopped that isolated server and will use a release build of the merged branch before recording the baseline matrix.
Author
Owner

Current-source release build first stopped because the ignored production embed directory apps/web/build/ is absent (RustEmbed in crates/calternal-server/src/main.rs:73). The app build then confirmed that workspace JS dependencies are not installed (vite: command not found). I’m installing from the frozen root bun.lock and building the frontend so I can complete the valid lock-enabled perf baseline.

Current-source release build first stopped because the ignored production embed directory `apps/web/build/` is absent (`RustEmbed` in `crates/calternal-server/src/main.rs:73`). The app build then confirmed that workspace JS dependencies are not installed (`vite: command not found`). I’m installing from the frozen root `bun.lock` and building the frontend so I can complete the valid lock-enabled perf baseline.
Author
Owner

The current-source class 2 server is staged in the isolated perf instance. At the first measurement attempt, lslocks showed /root/perf.lock held by another Python workload (elapsed 03:46 at inspection), so the baseline matrix is queued on flock; it will record uptime after acquiring the lock. The local source changes do not affect the staged pre-change server.

The current-source class 2 server is staged in the isolated perf instance. At the first measurement attempt, `lslocks` showed `/root/perf.lock` held by another Python workload (elapsed 03:46 at inspection), so the baseline matrix is queued on `flock`; it will record `uptime` after acquiring the lock. The local source changes do not affect the staged pre-change server.
Author
Owner

RFC/code review found that the existing custom mutation helper flattened every positive token in If, regardless of its tagged resource URI. dav-server evaluates each list against its tagged path, so using the flattened list for parent-collection checks could let a token for a different resource satisfy that check. I’ve changed the DAV helper to associate tokens with the request or tagged resource path and added a focused regression test; the adversarial round will exercise the behavior through LOCK/PUT/MOVE/DELETE.

RFC/code review found that the existing custom mutation helper flattened every positive token in `If`, regardless of its tagged resource URI. `dav-server` evaluates each list against its tagged path, so using the flattened list for parent-collection checks could let a token for a different resource satisfy that check. I’ve changed the DAV helper to associate tokens with the request or tagged resource path and added a focused regression test; the adversarial round will exercise the behavior through LOCK/PUT/MOVE/DELETE.
Author
Owner

Benchmark correction: the pre-change matrix has not started. lslocks and ps on the perf VM showed /root/perf.lock held by this job’s own /run/webdav-lock-476-log.py, which inherited the lock file descriptor during setup; a queued baseline was waiting behind it. I am restarting the isolated log collector without the inherited descriptor. No benchmark results from this attempt are valid.

Benchmark correction: the pre-change matrix has not started. `lslocks` and `ps` on the perf VM showed `/root/perf.lock` held by this job’s own `/run/webdav-lock-476-log.py`, which inherited the lock file descriptor during setup; a queued baseline was waiting behind it. I am restarting the isolated log collector without the inherited descriptor. No benchmark results from this attempt are valid.
Author
Owner

Correction: I found both the isolated server launcher (runuser) and log collector inherited the /root/perf.lock descriptor. I restarted both outside the lock. One queued attempt acquired the lock while the server was restarting, failed its OPTIONS connection, and exited before writing a benchmark result; that attempt is discarded. The valid pre-change matrix has now started under the lock. The staged server SHA-256 matches the local pre-change release: 487bc19e183bd17d7f21a61b7bf9fe983843d85e372dae27bb7aefadd13a4344.

Correction: I found both the isolated server launcher (`runuser`) and log collector inherited the `/root/perf.lock` descriptor. I restarted both outside the lock. One queued attempt acquired the lock while the server was restarting, failed its OPTIONS connection, and exited before writing a benchmark result; that attempt is discarded. The valid pre-change matrix has now started under the lock. The staged server SHA-256 matches the local pre-change release: `487bc19e183bd17d7f21a61b7bf9fe983843d85e372dae27bb7aefadd13a4344`.
Author
Owner

Pre-change ext4 baseline finding (perf VM, load sampled while /root/perf.lock was held): 32 concurrent unlocked 100 MB PUTs into different folders completed in 87.48 s, with 84.91 s p95 per PUT and 34.89 MiB/s aggregate throughput. The same-folder case was comparable. This is the global write contention #476 targets. The matrix is finishing its remaining locked/different-folder row; full before/after data will follow.

Pre-change ext4 baseline finding (perf VM, load sampled while `/root/perf.lock` was held): 32 concurrent unlocked 100 MB PUTs into different folders completed in 87.48 s, with 84.91 s p95 per PUT and 34.89 MiB/s aggregate throughput. The same-folder case was comparable. This is the global write contention #476 targets. The matrix is finishing its remaining locked/different-folder row; full before/after data will follow.
Author
Owner

HDD emulation baseline (all 8 combinations at 1 MB, on /dev/mapper/calternal-hdd-emu, 8 ms read/write delay) is complete under /root/perf.lock. The 32-upload same-folder case took 92.65 s unlocked and 180.37 s with LOCK; locked throughput was 0.17 MiB/s and p95 PUT latency was 111.97 s. A linear projection for one 32 × 100 MB case is over five hours, so the 100 MB HDD rows are not measured and will remain a reported timebox gap; I am not treating the projection as a result. The complete 100 MB matrix continues on ext4.

HDD emulation baseline (all 8 combinations at 1 MB, on `/dev/mapper/calternal-hdd-emu`, 8 ms read/write delay) is complete under `/root/perf.lock`. The 32-upload same-folder case took 92.65 s unlocked and 180.37 s with LOCK; locked throughput was 0.17 MiB/s and p95 PUT latency was 111.97 s. A linear projection for one 32 × 100 MB case is over five hours, so the 100 MB HDD rows are not measured and will remain a reported timebox gap; I am not treating the projection as a result. The complete 100 MB matrix continues on ext4.
Author
Owner

Current-source ext4 benchmark finding: the first two 8-worker, 1 MB same-folder cases passed (unlocked throughput 8.33 MiB/s; locked 5.68 MiB/s). The 32-worker same-folder unlocked case returned HTTP 500 for 9 of 32 PUTs. The benchmark aborted, so its partial after results are invalid and no after matrix has been recorded. I am tracing and fixing this 5xx before restarting performance or adversarial probes.

Current-source ext4 benchmark finding: the first two 8-worker, 1 MB same-folder cases passed (unlocked throughput 8.33 MiB/s; locked 5.68 MiB/s). The 32-worker same-folder unlocked case returned HTTP 500 for 9 of 32 PUTs. The benchmark aborted, so its partial after results are invalid and no after matrix has been recorded. I am tracing and fixing this 5xx before restarting performance or adversarial probes.
Author
Owner

Code finding while tracing the 500s: FileDavError::ServiceUnavailable and FileDavError::Internal both become FsError::GeneralFailure, so the DAV response loses its original status and has no body. This may explain the observed 500, but I have not confirmed the source failure yet. I added temporary-safe diagnostics in the Files DAV adapter that log only the static status, error code and message, without a User, path, payload or token. I will keep only the diagnostics that help the finished route remain operable.

Code finding while tracing the 500s: `FileDavError::ServiceUnavailable` and `FileDavError::Internal` both become `FsError::GeneralFailure`, so the DAV response loses its original status and has no body. This may explain the observed 500, but I have not confirmed the source failure yet. I added temporary-safe diagnostics in the Files DAV adapter that log only the static status, error code and message, without a User, path, payload or token. I will keep only the diagnostics that help the finished route remain operable.
Author
Owner

Source inspection found that Files permits only 16 active uploads per User (MAX_ACTIVE_UPLOADS), while the requested Finder profile opens 32 simultaneous PUTs. A rejected slot uses HTTP 429, which the DAV adapter maps to FileDavError::ServiceUnavailable; the DAV callback layer currently turns that into a generic 500. The 32-PUT probe saw 13/32 responses as 500, consistent with the slot limit, although the perf VM is now unreachable so its new diagnostic log is not available to confirm the exact code. I am raising the slot limit above the requested burst, preserving 503 for genuine service-unavailable errors, and adding a 32-upload regression test. SSH to 10.69.69.63 currently returns No route to host; I will retry before final measurements.

Source inspection found that Files permits only 16 active uploads per User (`MAX_ACTIVE_UPLOADS`), while the requested Finder profile opens 32 simultaneous PUTs. A rejected slot uses HTTP 429, which the DAV adapter maps to `FileDavError::ServiceUnavailable`; the DAV callback layer currently turns that into a generic 500. The 32-PUT probe saw 13/32 responses as 500, consistent with the slot limit, although the perf VM is now unreachable so its new diagnostic log is not available to confirm the exact code. I am raising the slot limit above the requested burst, preserving 503 for genuine service-unavailable errors, and adding a 32-upload regression test. SSH to 10.69.69.63 currently returns `No route to host`; I will retry before final measurements.
Author
Owner

The local WebDAV probe exposed a lock-scope bug: a token-authorized PUT below a Depth-infinity Home lock returned 423 before the DAV lock system checked the child URL. The extra parent-membership check treated the recursive lock as a direct Depth-0 collection lock. I changed the check to cover only a direct Depth-0 parent lock; DAV still checks Depth-infinity locks against the member URL. The 32-worker status storm also reached the four-permit Argon2 verifier's bounded wait and returned its intended 429 before lock checks. I narrowed the conflict probe to eight concurrent operations so it tests lock statuses; the PUT benchmark still exercises 32 concurrent transfers.

The local WebDAV probe exposed a lock-scope bug: a token-authorized PUT below a Depth-infinity Home lock returned 423 before the DAV lock system checked the child URL. The extra parent-membership check treated the recursive lock as a direct Depth-0 collection lock. I changed the check to cover only a direct Depth-0 parent lock; DAV still checks Depth-infinity locks against the member URL. The 32-worker status storm also reached the four-permit Argon2 verifier's bounded wait and returned its intended 429 before lock checks. I narrowed the conflict probe to eight concurrent operations so it tests lock statuses; the PUT benchmark still exercises 32 concurrent transfers.
Author
Owner

The focused real-server WebDAV adversarial rerun passed after the path-scope and Depth-infinity fixes: WebDAV scripted probes passed. Litmus completed 41 checks with 36 passing and the same five recognized failures: owner_modify (three cases), complex_cond_put, and fail_complex_cond_put (all documented as known by the probe). The LOCK/PUT/MOVE/DELETE contention storm returned the expected 423 responses, and the stale strong ETag race returned 412.

The perf VM remains unreachable (ssh root@10.69.69.63: No route to host). I am running the requested before/after matrix locally against the same ext4 host and real DAV fixture, with per-case host load recorded. The HDD emulation exists only on that VM, so it cannot be measured in this run.

The focused real-server WebDAV adversarial rerun passed after the path-scope and Depth-infinity fixes: `WebDAV scripted probes passed`. Litmus completed 41 checks with 36 passing and the same five recognized failures: `owner_modify` (three cases), `complex_cond_put`, and `fail_complex_cond_put` (all documented as known by the probe). The LOCK/PUT/MOVE/DELETE contention storm returned the expected 423 responses, and the stale strong ETag race returned 412. The perf VM remains unreachable (`ssh root@10.69.69.63`: `No route to host`). I am running the requested before/after matrix locally against the same ext4 host and real DAV fixture, with per-case host load recorded. The HDD emulation exists only on that VM, so it cannot be measured in this run.
Author
Owner

Implementation decisions for #476 where DESIGN did not prescribe the internal gate layout:

  • Keep the Files API upload cap at 16. Give DAV a separate cap of 64 so Finder can stage 32 parallel PUTs with headroom without changing Files API behavior.
  • Key mutation gates by User and canonical DAV resource bytes. Same-resource writes and tree removals take exclusive gates; distinct collection members share the parent membership gate. Acquire gates in key order so MOVE and COPY cannot deadlock.
  • Apply a direct collection lock to member URL changes for Depth 0. Let Depth infinity cover member resources through the normal DAV lock check, as RFC 4918 §7.4 requires.
  • Bound in-memory live lock state to 1024 leases per User. Each lease has a finite maximum timeout.
Implementation decisions for #476 where DESIGN did not prescribe the internal gate layout: - Keep the Files API upload cap at 16. Give DAV a separate cap of 64 so Finder can stage 32 parallel PUTs with headroom without changing Files API behavior. - Key mutation gates by User and canonical DAV resource bytes. Same-resource writes and tree removals take exclusive gates; distinct collection members share the parent membership gate. Acquire gates in key order so MOVE and COPY cannot deadlock. - Apply a direct collection lock to member URL changes for Depth 0. Let Depth infinity cover member resources through the normal DAV lock check, as RFC 4918 §7.4 requires. - Bound in-memory live lock state to 1024 leases per User. Each lease has a finite maximum timeout.
Author
Owner

The local pre-change benchmark exposed the 32-session cap: in the 100M / same folder / n=32 / unlocked case, 6 of 32 PUTs returned HTTP 429. The old DAV provider called the shared Files API upload creator, which enforced MAX_ACTIVE_UPLOADS = 16. Ten earlier cases completed. This is a before-side failure, not a current-source result. I am updating the benchmark to record failed upload counts and continue so it can finish all cases and compare the DAV-specific cap of 64.

The local pre-change benchmark exposed the 32-session cap: in the `100M / same folder / n=32 / unlocked` case, 6 of 32 PUTs returned HTTP 429. The old DAV provider called the shared Files API upload creator, which enforced `MAX_ACTIVE_UPLOADS = 16`. Ten earlier cases completed. This is a before-side failure, not a current-source result. I am updating the benchmark to record failed upload counts and continue so it can finish all cases and compare the DAV-specific cap of 64.
Author
Owner

Correction to my previous benchmark comment: a later run of the same pre-change binary and same 100 MB / same-folder / n=32 / unlocked case completed 32 of 32 PUTs. It took 226.24 seconds with p95 PUT latency 219,937.83 ms; load average was 19.79 at start and 14.23 at end. The old DAV path does share the 16-session Files API cap, but these runs do not establish that it caused the earlier six 429s. I am recording overload statuses by case and will report the initial 429 as transient rather than attribute it to that cap.

Correction to my previous benchmark comment: a later run of the same pre-change binary and same 100 MB / same-folder / n=32 / unlocked case completed 32 of 32 PUTs. It took 226.24 seconds with p95 PUT latency 219,937.83 ms; load average was 19.79 at start and 14.23 at end. The old DAV path does share the 16-session Files API cap, but these runs do not establish that it caused the earlier six 429s. I am recording overload statuses by case and will report the initial 429 as transient rather than attribute it to that cap.
Author
Owner

Local WebDAV lock benchmark finding for #476:

The perf VM was unreachable (ssh returned No route to host), so this is a local ext4 measurement with concurrent host work. The 100 MB same-folder, 32-worker unlocked case accepted 32/32 PUTs in 271.77 s at 11.23 MiB/s; PUT p95 was 260.72 s (host load 21.72 to 21.60). The matching locked case accepted 31/32 PUTs, then recorded 31 transport timeouts and one connection reset across its LOCK/PUT/UNLOCK transactions; it took 1,231.34 s and host load rose from 21.60 to 33.31. The local comparison is load-confounded. I am continuing the remaining matrix pairs once; no rerun is planned.

Local WebDAV lock benchmark finding for #476: The perf VM was unreachable (`ssh` returned `No route to host`), so this is a local ext4 measurement with concurrent host work. The 100 MB same-folder, 32-worker unlocked case accepted 32/32 PUTs in 271.77 s at 11.23 MiB/s; PUT p95 was 260.72 s (host load 21.72 to 21.60). The matching locked case accepted 31/32 PUTs, then recorded 31 transport timeouts and one connection reset across its LOCK/PUT/UNLOCK transactions; it took 1,231.34 s and host load rose from 21.60 to 33.31. The local comparison is load-confounded. I am continuing the remaining matrix pairs once; no rerun is planned.
Author
Owner

Additional local diagnostic during the 100 MB, 32-worker locked case:

Unauthenticated DAV OPTIONS returned 401 in 35 ms, and an authenticated PROPFIND returned 207 in 333 ms. A single authenticated LOCK to a different absent path timed out after 15 s through the proxy and again through the backend; LOCK on an existing benchmark file and an empty PUT to a separate path also timed out after 15 s. These probes were not part of the measured matrix. They show that reads/authentication stayed responsive while lock and write requests stalled under the concurrent run. Host load was above 20. I am letting the one local matrix finish to capture whether later cases recover; cause is not established yet.

Additional local diagnostic during the 100 MB, 32-worker locked case: Unauthenticated DAV OPTIONS returned 401 in 35 ms, and an authenticated PROPFIND returned 207 in 333 ms. A single authenticated LOCK to a different absent path timed out after 15 s through the proxy and again through the backend; LOCK on an existing benchmark file and an empty PUT to a separate path also timed out after 15 s. These probes were not part of the measured matrix. They show that reads/authentication stayed responsive while lock and write requests stalled under the concurrent run. Host load was above 20. I am letting the one local matrix finish to capture whether later cases recover; cause is not established yet.
Author
Owner

The local matrix is now at 12/16 cases. The next 100 MB, different-folder, 8-worker case has not reached measurement: its path-preparation MKCOL is still waiting after more than 7 minutes, before the benchmark creates upload workers. The host one-minute load average is about 31. An unauthenticated DAV OPTIONS and authenticated PROPFIND still returned promptly. I am preserving this run's results and will not repeat it to seek a quieter host.

The local matrix is now at 12/16 cases. The next 100 MB, different-folder, 8-worker case has not reached measurement: its path-preparation MKCOL is still waiting after more than 7 minutes, before the benchmark creates upload workers. The host one-minute load average is about 31. An unauthenticated DAV OPTIONS and authenticated PROPFIND still returned promptly. I am preserving this run's results and will not repeat it to seek a quieter host.
Author
Owner

#476 final report

Head: 3eb63adb2b54633c96d5064ef2c2ca17be03fe85

Built

  • DAV writes now take ordered gates for the exact resource, its collection membership, and affected subtrees. Sibling resource writes can share parent checks; overlapping moves, deletes, locks, and writes still wait.
  • Added RFC 4918 Depth 0 parent-lock checks and kept Depth infinity member checks in the DAV lock system. The adversarial probe now races LOCK, PUT, MOVE, and DELETE on overlapping paths, and checks stale 412 and complete-file outcomes.
  • Kept the Files API cap at 16 active uploads. DAV has a separate cap of 64 so Finder can stage 32 parallel PUTs.
  • Recorded the available before/after measurements in docs/perf/baseline.json.

Files: crates/calternal-dav/src/files.rs, crates/plugins/files/src/dav.rs, crates/plugins/files/src/uploads.rs, tests/adversarial/webdav.py, bench/webdav-lock-476.py, docs/perf/baseline.json.

Performance

The perf VM returned No route to host, so both binaries ran on the same local ext4 host. The baseline has 16 before cases and 12 after cases. For 1 MB, different-folder, 32-worker unlocked PUTs, throughput changed from 1.77 to 4.50 MiB/s and PUT p95 from 17,006.76 to 6,633.63 ms; both runs accepted 32/32 uploads.

The large-file results are load-confounded. Same-folder, 100 MB, 32-worker unlocked PUTs changed from 13.49 MiB/s and 219,937.83 ms p95 to 11.23 MiB/s and 260,718.69 ms p95; both accepted 32/32. In the matching locked after case, 31/32 PUTs succeeded, and the client transactions recorded 31 timeouts and one connection reset over 1,231.34 s as host load rose from 21.60 to 33.31.

The next after case timed out during folder setup: its MKCOL waited for the benchmark client's 900 second timeout before measurement. The last three 100 MB different-folder cases are marked unmeasured in the baseline. I did not repeat the local matrix. The perf VM and HDD emulation remain unmeasured.

Gates and probes

cargo fmt --all --check
(no output; exit 0)

cargo clippy -p calternal-dav --all-targets -- -D warnings
Finished `dev` profile [unoptimized + debuginfo] target(s) in 16.24s

cargo test -p calternal-dav
test result: ok. 45 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.14s
test result: ok. 36 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.04s

cargo clippy -p calternal-plugin-files --all-targets -- -D warnings
Finished `dev` profile [unoptimized + debuginfo] target(s) in 12.36s

cargo test -p calternal-plugin-files
147 passed; 0 failed; 1 ignored (reported result; the full harness line and duration were not retained)

The real-server WebDAV scripted probe passed. Litmus reported 36/41; its five known 4xx exceptions remain: three dead-property PROPPATCH cases return 403, and two long conditional PUT cases return 400 because Litmus 0.13 truncates the ETag-bearing If header. The configured probe treats those as known exceptions.

Decisions and gaps

  • Keep locks in memory, scoped by User and canonical DAV resource path, with a 1,024 live-lock cap per User and a finite timeout of up to 600 seconds.
  • Use shared parent membership gates for sibling members, exclusive resource gates for direct writes, and exclusive subtree gates for tree removal or Depth infinity lock scope. Acquire gate keys in order.
  • Keep the Files API upload cap at 16 and use 64 only for DAV.
  • Use local ext4 measurements because the designated perf VM was unreachable. Do not treat the overloaded 100 MB comparison as a stable speedup measurement.
  • Known gap: four after cases have no measurements because the case setup MKCOL timed out under high host load. The stalled local write/lock behavior is recorded on this issue and in the baseline for owner review.
#476 final report Head: `3eb63adb2b54633c96d5064ef2c2ca17be03fe85` ## Built - DAV writes now take ordered gates for the exact resource, its collection membership, and affected subtrees. Sibling resource writes can share parent checks; overlapping moves, deletes, locks, and writes still wait. - Added RFC 4918 Depth 0 parent-lock checks and kept Depth infinity member checks in the DAV lock system. The adversarial probe now races LOCK, PUT, MOVE, and DELETE on overlapping paths, and checks stale 412 and complete-file outcomes. - Kept the Files API cap at 16 active uploads. DAV has a separate cap of 64 so Finder can stage 32 parallel PUTs. - Recorded the available before/after measurements in `docs/perf/baseline.json`. Files: `crates/calternal-dav/src/files.rs`, `crates/plugins/files/src/dav.rs`, `crates/plugins/files/src/uploads.rs`, `tests/adversarial/webdav.py`, `bench/webdav-lock-476.py`, `docs/perf/baseline.json`. ## Performance The perf VM returned `No route to host`, so both binaries ran on the same local ext4 host. The baseline has 16 before cases and 12 after cases. For 1 MB, different-folder, 32-worker unlocked PUTs, throughput changed from 1.77 to 4.50 MiB/s and PUT p95 from 17,006.76 to 6,633.63 ms; both runs accepted 32/32 uploads. The large-file results are load-confounded. Same-folder, 100 MB, 32-worker unlocked PUTs changed from 13.49 MiB/s and 219,937.83 ms p95 to 11.23 MiB/s and 260,718.69 ms p95; both accepted 32/32. In the matching locked after case, 31/32 PUTs succeeded, and the client transactions recorded 31 timeouts and one connection reset over 1,231.34 s as host load rose from 21.60 to 33.31. The next after case timed out during folder setup: its MKCOL waited for the benchmark client's 900 second timeout before measurement. The last three 100 MB different-folder cases are marked unmeasured in the baseline. I did not repeat the local matrix. The perf VM and HDD emulation remain unmeasured. ## Gates and probes ```text cargo fmt --all --check (no output; exit 0) cargo clippy -p calternal-dav --all-targets -- -D warnings Finished `dev` profile [unoptimized + debuginfo] target(s) in 16.24s cargo test -p calternal-dav test result: ok. 45 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.14s test result: ok. 36 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.04s cargo clippy -p calternal-plugin-files --all-targets -- -D warnings Finished `dev` profile [unoptimized + debuginfo] target(s) in 12.36s cargo test -p calternal-plugin-files 147 passed; 0 failed; 1 ignored (reported result; the full harness line and duration were not retained) ``` The real-server WebDAV scripted probe passed. Litmus reported 36/41; its five known 4xx exceptions remain: three dead-property PROPPATCH cases return 403, and two long conditional PUT cases return 400 because Litmus 0.13 truncates the ETag-bearing If header. The configured probe treats those as known exceptions. ## Decisions and gaps - Keep locks in memory, scoped by User and canonical DAV resource path, with a 1,024 live-lock cap per User and a finite timeout of up to 600 seconds. - Use shared parent membership gates for sibling members, exclusive resource gates for direct writes, and exclusive subtree gates for tree removal or Depth infinity lock scope. Acquire gate keys in order. - Keep the Files API upload cap at 16 and use 64 only for DAV. - Use local ext4 measurements because the designated perf VM was unreachable. Do not treat the overloaded 100 MB comparison as a stable speedup measurement. - Known gap: four after cases have no measurements because the case setup MKCOL timed out under high host load. The stalled local write/lock behavior is recorded on this issue and in the baseline for owner review.
Author
Owner

Results

Profile dev c4a61e8 job/webdav-lock-476 3eb63ad
WebDAV PUT matrix: 1 MB/100 MB, 32 workers, same/different folder, locked/unlocked Not measured before the reporting cutoff Not measured before the reporting cutoff

No latency, CPU or RSS samples exist; no regression is inferred. The six interleaved A/B runs needed for this matrix did not fit in the perf-VM time window.

Command

The prepared runner would invoke /root/perf-rerun/run_aux_profile.py webdav --server <dev-or-feature-release-binary> --output /root/perf-rerun/output/webdav-<label>.json --commit <matching-SHA>. It seeds a real User and runs the eight requested matrix cases with --sizes 1M,100M --concurrency 32 --layouts same,different --locks off,on --continue-on-failure, under /root/hdd-emu.sh run-limited, TMPDIR=/srv/hdd-emu/tmp and flock -w 14400 /root/perf.lock.

## Results | Profile | dev `c4a61e8` | `job/webdav-lock-476` `3eb63ad` | | --- | --- | --- | | WebDAV PUT matrix: 1 MB/100 MB, 32 workers, same/different folder, locked/unlocked | Not measured before the reporting cutoff | Not measured before the reporting cutoff | No latency, CPU or RSS samples exist; no regression is inferred. The six interleaved A/B runs needed for this matrix did not fit in the perf-VM time window. ## Command The prepared runner would invoke `/root/perf-rerun/run_aux_profile.py webdav --server <dev-or-feature-release-binary> --output /root/perf-rerun/output/webdav-<label>.json --commit <matching-SHA>`. It seeds a real User and runs the eight requested matrix cases with `--sizes 1M,100M --concurrency 32 --layouts same,different --locks off,on --continue-on-failure`, under `/root/hdd-emu.sh run-limited`, `TMPDIR=/srv/hdd-emu/tmp` and `flock -w 14400 /root/perf.lock`.
Author
Owner

Starting the macinterop job requested by the owner. Scope: real Calendar, Reminders, Notes and Finder tests, with defects filed separately; no product optimisation in this job. Tested build is detached origin/job/merge-round-7a at daea49a7f0. Original job branch: job/macinterop. Mac lock acquired. Existing 2026-10-01/02 lab results are reference only; this run will retest the requested build.

Starting the macinterop job requested by the owner. Scope: real Calendar, Reminders, Notes and Finder tests, with defects filed separately; no product optimisation in this job. Tested build is detached origin/job/merge-round-7a at daea49a7f0a16fbc382614761e5f9f05ec077c7b. Original job branch: job/macinterop. Mac lock acquired. Existing 2026-10-01/02 lab results are reference only; this run will retest the requested build.
Author
Owner

Lab finding: the old local data directory and TLS key files recorded in macdav-lab/start-server.sh do not exist after the reboot. The Mac still has the calternal profile, its cached calendars and the old trusted CA. A fresh User needs a new lab profile and certificate. The real Calendar window currently shows a connection warning; this is lab state, not evidence of a product defect. Production web build passed. The server build ended with signal 15 before a binary was produced; retrying once, with four build jobs and without the stalled shared compiler cache.

Lab finding: the old local data directory and TLS key files recorded in macdav-lab/start-server.sh do not exist after the reboot. The Mac still has the calternal profile, its cached calendars and the old trusted CA. A fresh User needs a new lab profile and certificate. The real Calendar window currently shows a connection warning; this is lab state, not evidence of a product defect. Production web build passed. The server build ended with signal 15 before a binary was produced; retrying once, with four build jobs and without the stalled shared compiler cache.
Author
Owner

Status: BLOCKED. The real-client interop matrix is not complete.

The Mac is reachable and runs macOS 27.0 (26A428), with cua-driver 0.30.2. I held the Mac lock for all Mac sessions. The existing calternal profile and cached calendars remain on the Mac. The local data and TLS key files named by the old lab scripts do not exist after the reboot. A replacement certificate reaches the Mac, but the Mac does not trust its new CA.

Build and files

  • Checkout/head: daea49a7f0a16fbc382614761e5f9f05ec077c7b, detached from origin/job/merge-round-7a.
  • The worktree server build did not complete. The initial build ended with signal 15; the retry was stopped when the trust blocker was established.
  • For lab preparation I used the merge job's compiled server, read only. /api/v1/system/info reported 2f4482ded066d9c5d9c59130377907f7fd2916c9. git diff 2f4482ded..daea49a7f contains only 11 added lines in tests/adversarial/authz_matrix.py and tests/adversarial/xuser_matrix.py; product code is identical. This is not a claim that the requested checkout's own build passed.
  • The production web build passed. The real passkey APIs created a disposable User, App Password and Mac configuration profile. The profile was copied privately to Mac Downloads and opened, but was not installed.
  • No tracked files changed and no commits were made: this job was testing only. No product fix, push, deploy or merge was performed.
  • Evidence and local preparation scripts: artifacts/macinterop/ (ignored). Screenshots are attached below.

App × flow matrix

App Flow Result / issue
Lab setup Mac access, existing profile and cached calendars PASS, read only; does not prove authentication
Lab setup HTTPS with normal certificate verification BLOCKED: replacement CA is not trusted; lab prerequisite, no product issue
Calendar Fresh account discovery UNTESTED
Calendar Create, edit, move and delete timed events UNTESTED
Calendar All-day, recurrence with an exception, alarm and time zone UNTESTED
Calendar Web ↔ Mac edits and refresh UNTESTED
Calendar Two calendars and calendar deletion UNTESTED
Reminders Create, complete, due dates and lists UNTESTED
Reminders Tasks ↔ Mac round trip UNTESTED
Notes Create, edit and delete on both sides UNTESTED
Notes Attachments, folders and duplicate checks across sync cycles UNTESTED
Finder Cmd+K, mixed folder, 500 MB file, NFD/emoji/spaces UNTESTED
Finder TextEdit open/save, rename, move, delete and Trash UNTESTED
Finder Hidden Apple metadata and disconnect/reconnect UNTESTED

No new product defect is confirmed. Existing #643–#648 results in the previous lab notes were not retested and are not counted as passes or failures for this run.

Evidence and logs

  • Real Calendar window: cached lab calendars and connection warning.
  • Real Safari window: lab secure connection failure. This image was taken during tunnel diagnosis; it is not evidence of a server API defect.
  • Device Management: replacement profile downloaded, not installed.
  • After the tunnel was corrected, real Mac curl reported SSL certificate problem: self signed certificate in certificate chain and curl: (60) SSL certificate problem: self signed certificate in certificate chain. The transcript is in artifacts/macinterop/mac-tls-verification.txt.
  • Zero DAV requests reached the server. The proxy recorded one 502 from a local health check before the upstream server was started; this is a lab startup error, not a product finding. There is no evidence for any DAV retry or request-latency result.
  • Server startup logged slow SQLite acquisition/queries on this busy host. These are SLOW-only observations, not an interop or benchmark result.

Owner recovery steps

  1. Prefer restoring the old lab CA signing key and leaf certificate, if a backup exists. This preserves the Mac's existing lab certificate trust.
  2. Otherwise use the replacement public root.pem in ~/.local/state/codex-jobs/calternal/macdav-lab/macinterop-2026-10-02-tls/. Import only that lab CA into Keychain Access → System, open its Trust settings, set it to Always Trust, and complete the macOS authorization prompt. The SHA-256 fingerprint is 95:33:54:D8:43:45:EE:89:EE:46:4A:81:4C:69:E3:37:92:27:06:AE:FC:F1:84:92:17:11:75:39:A8:AD:AA:DD. This certificate expires on 2026-10-05 at 14:54:55 UTC; replace it if recovery occurs later. I did not change certificate trust or other Mac settings.
  3. A subsequent job must start a fresh disposable server, create a fresh User and App Password, and replace only the old calternal lab profile in System Settings → General → Device Management. The profile from this run is invalid after cleanup and must not be installed. macOS may show its downloaded copy until the pending profile expires.
  4. Run the full matrix above with normal TLS verification. The job's Mac rule requires these extra trust/authorization steps to be listed for the owner, not performed through an unavailable password prompt.

Gate output, verbatim

✓ built in 1m 16s

> Using @sveltejs/adapter-static
  Wrote site to "build"
  ✔ done
cargo fmt --check exit: 0
     Removed 3797 files, 1.6GiB total
cargo clean exit: 0

No crate or web source changed, so per-crate clippy/test and web check/test were not run. No final integration merge was needed for a source change; the detached build under test was kept unchanged. No feature or route was added, so no bench profile was added. No adversarial product round ran: the required real-client prerequisite did not pass.

Cleanup, verified

MAC_TEMPORARY_FILES_REMOVED
PORT CLOSED 18088
PORT CLOSED 8443
PORT CLOSED 31993
PORT CLOSED 31465
LAB_DATA_AND_CREDENTIALS_REMOVED
Request count: 1 DAV request count: 0

The lab server, TLS proxy and three tunnels are stopped. The disposable Home, index, App Password/profile/session files and web output are removed. The retained server log has its setup token redacted. The Mac lock is released. Only private lab TLS recovery material is kept outside the repo; it contains no User data.

Decisions: treat connection/trust failures as lab prerequisites, not product defects; use the existing binary only after proving product-code equality and report its embedded revision; retain lab TLS material privately so the next run can reuse the same CA. No product design decision was made.

UX gaps closed: none; no product UI was changed. UX gaps left / known gaps: all requested authenticated client flows, all prior defect retests, the 500 MB transfer, sync-cycle duplicate checks and latency/retry observations remain untested. This report does not satisfy the real-client deploy gate.

**Status: BLOCKED. The real-client interop matrix is not complete.** The Mac is reachable and runs macOS 27.0 (26A428), with cua-driver 0.30.2. I held the Mac lock for all Mac sessions. The existing calternal profile and cached calendars remain on the Mac. The local data and TLS key files named by the old lab scripts do not exist after the reboot. A replacement certificate reaches the Mac, but the Mac does not trust its new CA. **Build and files** - Checkout/head: `daea49a7f0a16fbc382614761e5f9f05ec077c7b`, detached from `origin/job/merge-round-7a`. - The worktree server build did not complete. The initial build ended with signal 15; the retry was stopped when the trust blocker was established. - For lab preparation I used the merge job's compiled server, read only. `/api/v1/system/info` reported `2f4482ded066d9c5d9c59130377907f7fd2916c9`. `git diff 2f4482ded..daea49a7f` contains only 11 added lines in `tests/adversarial/authz_matrix.py` and `tests/adversarial/xuser_matrix.py`; product code is identical. This is not a claim that the requested checkout's own build passed. - The production web build passed. The real passkey APIs created a disposable User, App Password and Mac configuration profile. The profile was copied privately to Mac Downloads and opened, but was not installed. - No tracked files changed and no commits were made: this job was testing only. No product fix, push, deploy or merge was performed. - Evidence and local preparation scripts: `artifacts/macinterop/` (ignored). Screenshots are attached below. **App × flow matrix** | App | Flow | Result / issue | |---|---|---| | Lab setup | Mac access, existing profile and cached calendars | PASS, read only; does not prove authentication | | Lab setup | HTTPS with normal certificate verification | BLOCKED: replacement CA is not trusted; lab prerequisite, no product issue | | Calendar | Fresh account discovery | UNTESTED | | Calendar | Create, edit, move and delete timed events | UNTESTED | | Calendar | All-day, recurrence with an exception, alarm and time zone | UNTESTED | | Calendar | Web ↔ Mac edits and refresh | UNTESTED | | Calendar | Two calendars and calendar deletion | UNTESTED | | Reminders | Create, complete, due dates and lists | UNTESTED | | Reminders | Tasks ↔ Mac round trip | UNTESTED | | Notes | Create, edit and delete on both sides | UNTESTED | | Notes | Attachments, folders and duplicate checks across sync cycles | UNTESTED | | Finder | Cmd+K, mixed folder, 500 MB file, NFD/emoji/spaces | UNTESTED | | Finder | TextEdit open/save, rename, move, delete and Trash | UNTESTED | | Finder | Hidden Apple metadata and disconnect/reconnect | UNTESTED | No new product defect is confirmed. Existing #643–#648 results in the previous lab notes were not retested and are not counted as passes or failures for this run. **Evidence and logs** - [Real Calendar window: cached lab calendars and connection warning](https://git.kayg.org/attachments/0d0ddc93-4668-4828-8d77-1c5f1e0f066c). - [Real Safari window: lab secure connection failure](https://git.kayg.org/attachments/2a40c0a4-4dd6-4b0c-af04-fe816224ecb3). This image was taken during tunnel diagnosis; it is not evidence of a server API defect. - [Device Management: replacement profile downloaded, not installed](https://git.kayg.org/attachments/dc713427-296c-4918-b0e0-b11c2aa49b36). - After the tunnel was corrected, real Mac curl reported `SSL certificate problem: self signed certificate in certificate chain` and `curl: (60) SSL certificate problem: self signed certificate in certificate chain`. The transcript is in `artifacts/macinterop/mac-tls-verification.txt`. - Zero DAV requests reached the server. The proxy recorded one 502 from a local health check before the upstream server was started; this is a lab startup error, not a product finding. There is no evidence for any DAV retry or request-latency result. - Server startup logged slow SQLite acquisition/queries on this busy host. These are SLOW-only observations, not an interop or benchmark result. **Owner recovery steps** 1. Prefer restoring the old lab CA signing key and leaf certificate, if a backup exists. This preserves the Mac's existing lab certificate trust. 2. Otherwise use the replacement public `root.pem` in `~/.local/state/codex-jobs/calternal/macdav-lab/macinterop-2026-10-02-tls/`. Import only that lab CA into Keychain Access → System, open its Trust settings, set it to Always Trust, and complete the macOS authorization prompt. The SHA-256 fingerprint is `95:33:54:D8:43:45:EE:89:EE:46:4A:81:4C:69:E3:37:92:27:06:AE:FC:F1:84:92:17:11:75:39:A8:AD:AA:DD`. This certificate expires on 2026-10-05 at 14:54:55 UTC; replace it if recovery occurs later. I did not change certificate trust or other Mac settings. 3. A subsequent job must start a fresh disposable server, create a fresh User and App Password, and replace only the old calternal lab profile in System Settings → General → Device Management. The profile from this run is invalid after cleanup and must not be installed. macOS may show its downloaded copy until the pending profile expires. 4. Run the full matrix above with normal TLS verification. The job's Mac rule requires these extra trust/authorization steps to be listed for the owner, not performed through an unavailable password prompt. **Gate output, verbatim** ```text ✓ built in 1m 16s > Using @sveltejs/adapter-static Wrote site to "build" ✔ done ``` ```text cargo fmt --check exit: 0 Removed 3797 files, 1.6GiB total cargo clean exit: 0 ``` No crate or web source changed, so per-crate clippy/test and web check/test were not run. No final integration merge was needed for a source change; the detached build under test was kept unchanged. No feature or route was added, so no bench profile was added. No adversarial product round ran: the required real-client prerequisite did not pass. **Cleanup, verified** ```text MAC_TEMPORARY_FILES_REMOVED PORT CLOSED 18088 PORT CLOSED 8443 PORT CLOSED 31993 PORT CLOSED 31465 LAB_DATA_AND_CREDENTIALS_REMOVED Request count: 1 DAV request count: 0 ``` The lab server, TLS proxy and three tunnels are stopped. The disposable Home, index, App Password/profile/session files and web output are removed. The retained server log has its setup token redacted. The Mac lock is released. Only private lab TLS recovery material is kept outside the repo; it contains no User data. **Decisions:** treat connection/trust failures as lab prerequisites, not product defects; use the existing binary only after proving product-code equality and report its embedded revision; retain lab TLS material privately so the next run can reuse the same CA. No product design decision was made. **UX gaps closed:** none; no product UI was changed. **UX gaps left / known gaps:** all requested authenticated client flows, all prior defect retests, the 500 MB transfer, sync-cycle duplicate checks and latency/retry observations remain untested. This report does not satisfy the real-client deploy gate.
Author
Owner

Starting Round 2 on job/macinterop-staging-r2, base daea49a7f0a16fbc382614761e5f9f05ec077c7b. Scope: the owner-requested staging Apple-client matrix. HTTPS edge at 168.119.145.115 returns 200 with TLS verification 0. Public DNS and macOS dscacheutil both return 10.69.69.52. Server-side preparation proceeds; no Mac account changes until DNS resolves to the specified edge. Credentials remain in the private staging directory. No production changes.

Starting Round 2 on `job/macinterop-staging-r2`, base `daea49a7f0a16fbc382614761e5f9f05ec077c7b`. Scope: the owner-requested staging Apple-client matrix. HTTPS edge at 168.119.145.115 returns 200 with TLS verification 0. Public DNS and macOS dscacheutil both return 10.69.69.52. Server-side preparation proceeds; no Mac account changes until DNS resolves to the specified edge. Credentials remain in the private staging directory. No production changes.
Author
Owner

Preparation commit: 9a0a3fc39. node --check tests/manual/apple-staging-setup.mjs exited 0. A fresh node tests/manual/apple-staging-setup.mjs run printed:

interop-admin saved passkey sign-in passed
macinterop saved passkey sign-in passed
Test User, App Password and profile ready; secrets saved privately.

The admin and member User use separate virtual passkeys. Setup and invitation registration used the real browser forms. The setup admin needed recovery after the first automation checkbox timeout; its new key is private. The Mac DNS check now returns 168.119.145.115. Staging ss -ltn shows HTTP on 10.70.3.158:8080, no IMAP listener. The generated profile advertises dev.calternal.com:993; Notes is not exposed. No product code changed.

Preparation commit: `9a0a3fc39`. `node --check tests/manual/apple-staging-setup.mjs` exited 0. A fresh `node tests/manual/apple-staging-setup.mjs` run printed: ```text interop-admin saved passkey sign-in passed macinterop saved passkey sign-in passed Test User, App Password and profile ready; secrets saved privately. ``` The admin and member User use separate virtual passkeys. Setup and invitation registration used the real browser forms. The setup admin needed recovery after the first automation checkbox timeout; its new key is private. The Mac DNS check now returns `168.119.145.115`. Staging `ss -ltn` shows HTTP on `10.70.3.158:8080`, no IMAP listener. The generated profile advertises `dev.calternal.com:993`; Notes is not exposed. No product code changed.
Author
Owner

Real Mac evidence expands the impact of #858: installing the combined server-generated Calendar + Notes profile failed and rolled back Calendar as well. On macOS 27, mdmclient reported MailPayloadPlugin account-save failure, com.apple.accounts Code=1, nested error Code=60, Operation timed out connecting to dev.calternal.com on the default ports. The log then reported Install Failed and removed the calternal Calendar account payload. profiles list showed no calternal staging profile; Internet Accounts showed No accounts after Calendar/Reminders relaunch. No owner-password prompt appeared. HTTPS from the Mac returned 200 with TLS verification 0, and authenticated DAV discovery returned 207. The job will use a new server-generated profile with CalDAV access and no Notes scope to continue independent Calendar/Reminders testing. This does not verify Notes and does not change the edge.

Real Mac evidence expands the impact of #858: installing the combined server-generated Calendar + Notes profile failed and rolled back Calendar as well. On macOS 27, `mdmclient` reported `MailPayloadPlugin` account-save failure, `com.apple.accounts Code=1`, nested error `Code=60`, `Operation timed out` connecting to `dev.calternal.com` on the default ports. The log then reported `Install Failed` and removed the `calternal Calendar account` payload. `profiles list` showed no calternal staging profile; Internet Accounts showed `No accounts` after Calendar/Reminders relaunch. No owner-password prompt appeared. HTTPS from the Mac returned 200 with TLS verification 0, and authenticated DAV discovery returned 207. The job will use a new server-generated profile with CalDAV access and no Notes scope to continue independent Calendar/Reminders testing. This does not verify Notes and does not change the edge.
Author
Owner

Final Round 2 report. Branch job/macinterop-staging-r2, head c75a5b99a1514b3322778021e5447146eb957455. Merged origin/dev once at 6009232d7; no push or deploy.

Built tests/manual/apple-staging-setup.mjs: real browser setup/invitation/recovery and saved-passkey sign-in, private App Password/profile output, and an option to omit unavailable Notes. Recorded the matrix in docs/research/apple-staging-2026-10-02.md. No product changes. Module comments were read again before this report.

Apple staging check, 2026-10-02

This report records Round 2 of #476. It tests the staging image
c4a61e8cf090170f35b1bed3350d9de20c83ecd5. It does not certify a newer build.
See DESIGN §§7, 30, 31 and 48 for the account and adapter contracts.

Setup

The public and Mac DNS records reached 168.119.145.115. Native Mac HTTPS
validation passed. No hosts file, DNS setting or certificate trust setting
changed. The first administrator and a separate test User were created with
real browser forms and virtual passkeys. Credentials are in the private
staging directory, with mode 0600.

The old calternal lab profile was removed. The combined staging profile failed:
the IMAP connection timed out and macOS removed its Calendar payload. The
server-generated profile without Notes installed. Native Calendar and
Reminders discovered the staging calendars. Native NetFS mounted Files over
WebDAV. The first Connect to Server attempt stalled; the mount passed after
the test's authentication helpers were stopped and native NetFS retried.
The Mac lock was held for the entire check.

Results

“API” below means an authenticated request for this test User. A native check
uses the actual Mac application or its filesystem client. API-to-Mac checks
verify the adapter, not the browser's editor controls.

Surface and check Result Evidence or limit
Calendar: discovery and create in both directions PASS Untagged, Work and Fitness appeared; native and API Log entries arrived.
Calendar: title and time in both directions PASS Native 10:30–12:00 edit and API 13:00–14:00 edit matched.
Calendar: move to the next day PASS Same block ID moved from September 29 to September 30.
Calendar: delete in both directions PASS Native cross-midnight delete and API event delete reached the other side.
Calendar: Unicode, cross-midnight and display alarm PASS Unicode title and 23:00–01:00 time survived; the native 15-minute alarm remained in DAV. Notification delivery was not tested.
Calendar: two areas, edit one copy PASS One block ID and both tags remained after a native Fitness edit.
Calendar: delete one area copy PASS Fitness tag and calendar disappeared; Work copy and block ID remained.
Calendar: repeated sync PASS No duplicate R2 events in native readback.
Calendar: stale revision PASS Stale PUT returned 412; the stored event did not change.
Calendar: all-day, recurrence, description, location, URL LIMITED BY CONTRACT Functional DAV checks returned 422 for all-day and 403 for the other unsupported fields. No new native rejection-dialog check.
Calendar: create an area calendar from DAV LIMITED BY CONTRACT MKCALENDAR returned 403.
Calendar: native move between area calendars NOT VERIFIED No successful native MOVE check in this round.
Reminders: plain, timed and date-only create PASS Native records reached Tasks with correct date, time, priority and multiline body.
Reminders: native rename, body, priority and date edit PASS Date-only edit reached Tasks as October 9, low priority and the changed title/body.
Reminders: completion and API uncompletion PASS Status changed in Tasks; native readback showed uncompleted.
Reminders: delete in both directions PASS Native plain Task delete and API-created Task delete reached the other side.
Reminders: API-created title, due and priority edits PASS Native readback showed the edited title, October 10 and priority 9.
Reminders: API edit of an Apple-created Task FAIL #643 Due October 12 and low priority did not reach the Mac. Completion reverted both to October 8 and urgent.
Reminders: scheduled-only Task FAIL #647 Native due date was missing. Later native activity cleared the stored scheduled date and time.
Reminders: 21-item Unicode batch PASS 21 file Tasks and 21 distinct IDs; native list showed the Unicode names.
Reminders: standalone Task retitle FAIL #940 An extra inline Task appeared with the old canonical checkbox title.
Reminders: Flag, subtask and extra list controls NOT RETESTED Round 1 Apple limitations were not checked again.
Files: native mount, Unicode folder and filename PASS Native NetFS mount; NFD filename became NFC on the server.
Files: copy, read, append, rename, move and delete PASS Native byte checks passed; deleted entries were absent in DAV listing.
Files: 50 MB copy PASS Source, mounted read and independent DAV GET had identical SHA-256.
Files: 30 files in three levels PASS Recursive byte comparison, rename and delete passed.
Files: API folder create and rename to Mac PASS DAV MKCOL/MOVE returned 201; renamed folder was visible on the mount.
Files: copy extended attributes with cp FAIL #648 Both copies returned exit 1. All 17 content bytes survived; attributes did not. The earlier zero-byte result was not reproduced.
Files: Finder GUI metadata copy CONTENT PASS, METADATA FAIL #648 After copy completion, all 17 bytes matched. The extended attribute was absent.
Files: volume name KNOWN GAP #648 Finder uses the User ID as the volume name.
Notes: discovery, create, edit, move, delete and rich content NOT EXPOSED #858 No public IMAP route or staging IMAP listener with a valid certificate.

Verification and limits

The setup helper passed saved-passkey sign-in for both test accounts and
obtained a real App Password and profile. Setup and recovery browser flows
also passed during preparation. Final syntax, format and whitespace checks
passed. No Rust crate, route, background job or product UI changed, so crate
clippy/tests, web gates, responsive screenshots and a hot-path benchmark do
not apply to this change. The 50 MB check measures integrity, not performance.

A single functional DAV rejection check covered stale revision and documented
unsupported Calendar writes. It did not run a hostile-input campaign against
staging. Server journal capture showed no ERROR or panic lines; it is not a
complete HTTP status trace. No staging deployment or production change occurred.

UX gaps

No product UX gap was fixed by this test job. Findings are on #643, #647,
#648, #858 and #940. The two observed losses of Task properties must block
release. The Mac has notifications disabled for Reminders; the owner must
enable them before testing notification delivery. No password prompt was
needed for the final account installation.

Decisions

Use the server-generated profile without Notes after macOS rolled back the
combined profile. Leave Notes untested until its edge is available. Keep the
staging build unchanged so results refer to the owner's selected image.
These are test choices. No product design choice was added.

Mac screenshots and the full gate output are attached or quoted on #476.
Raw non-secret test evidence remains in artifacts/macinterop/staging-r2/.
Screenshots are not committed.

Gate output (verbatim)

cargo fmt --check: exit 0; no output
node --check tests/manual/apple-staging-setup.mjs: exit 0; no output
git diff --check: exit 0; no output
interop-admin saved passkey sign-in passed
macinterop saved passkey sign-in passed
Test User, App Password and profile ready; secrets saved privately.

Mac screenshots

Calendar before deletes

Calendar after deleting one area

Reminders Unicode batch and date-only Task

Finder 50 MB file and Unicode filename

The screenshots are from the real Mac. No product UI changed, so there is no responsive web screenshot set. Notifications remain disabled in macOS; enable them for a delivery test. The installed staging profile remains available; its private copy is preserved separately from later helper-generated profiles. The Mac lock and staging journal watch are released. cargo clean returned Removed 1 file, 356B total. The worktree is clean.

Final Round 2 report. Branch `job/macinterop-staging-r2`, head `c75a5b99a1514b3322778021e5447146eb957455`. Merged `origin/dev` once at `6009232d7`; no push or deploy. Built `tests/manual/apple-staging-setup.mjs`: real browser setup/invitation/recovery and saved-passkey sign-in, private App Password/profile output, and an option to omit unavailable Notes. Recorded the matrix in `docs/research/apple-staging-2026-10-02.md`. No product changes. Module comments were read again before this report. # Apple staging check, 2026-10-02 This report records Round 2 of #476. It tests the staging image `c4a61e8cf090170f35b1bed3350d9de20c83ecd5`. It does not certify a newer build. See DESIGN §§7, 30, 31 and 48 for the account and adapter contracts. ## Setup The public and Mac DNS records reached `168.119.145.115`. Native Mac HTTPS validation passed. No hosts file, DNS setting or certificate trust setting changed. The first administrator and a separate test User were created with real browser forms and virtual passkeys. Credentials are in the private staging directory, with mode 0600. The old calternal lab profile was removed. The combined staging profile failed: the IMAP connection timed out and macOS removed its Calendar payload. The server-generated profile without Notes installed. Native Calendar and Reminders discovered the staging calendars. Native NetFS mounted Files over WebDAV. The first Connect to Server attempt stalled; the mount passed after the test's authentication helpers were stopped and native NetFS retried. The Mac lock was held for the entire check. ## Results “API” below means an authenticated request for this test User. A native check uses the actual Mac application or its filesystem client. API-to-Mac checks verify the adapter, not the browser's editor controls. | Surface and check | Result | Evidence or limit | | --- | --- | --- | | Calendar: discovery and create in both directions | PASS | Untagged, Work and Fitness appeared; native and API Log entries arrived. | | Calendar: title and time in both directions | PASS | Native 10:30–12:00 edit and API 13:00–14:00 edit matched. | | Calendar: move to the next day | PASS | Same block ID moved from September 29 to September 30. | | Calendar: delete in both directions | PASS | Native cross-midnight delete and API event delete reached the other side. | | Calendar: Unicode, cross-midnight and display alarm | PASS | Unicode title and 23:00–01:00 time survived; the native 15-minute alarm remained in DAV. Notification delivery was not tested. | | Calendar: two areas, edit one copy | PASS | One block ID and both tags remained after a native Fitness edit. | | Calendar: delete one area copy | PASS | Fitness tag and calendar disappeared; Work copy and block ID remained. | | Calendar: repeated sync | PASS | No duplicate R2 events in native readback. | | Calendar: stale revision | PASS | Stale PUT returned 412; the stored event did not change. | | Calendar: all-day, recurrence, description, location, URL | LIMITED BY CONTRACT | Functional DAV checks returned 422 for all-day and 403 for the other unsupported fields. No new native rejection-dialog check. | | Calendar: create an area calendar from DAV | LIMITED BY CONTRACT | MKCALENDAR returned 403. | | Calendar: native move between area calendars | NOT VERIFIED | No successful native MOVE check in this round. | | Reminders: plain, timed and date-only create | PASS | Native records reached Tasks with correct date, time, priority and multiline body. | | Reminders: native rename, body, priority and date edit | PASS | Date-only edit reached Tasks as October 9, low priority and the changed title/body. | | Reminders: completion and API uncompletion | PASS | Status changed in Tasks; native readback showed uncompleted. | | Reminders: delete in both directions | PASS | Native plain Task delete and API-created Task delete reached the other side. | | Reminders: API-created title, due and priority edits | PASS | Native readback showed the edited title, October 10 and priority 9. | | Reminders: API edit of an Apple-created Task | FAIL #643 | Due October 12 and low priority did not reach the Mac. Completion reverted both to October 8 and urgent. | | Reminders: scheduled-only Task | FAIL #647 | Native due date was missing. Later native activity cleared the stored scheduled date and time. | | Reminders: 21-item Unicode batch | PASS | 21 file Tasks and 21 distinct IDs; native list showed the Unicode names. | | Reminders: standalone Task retitle | FAIL #940 | An extra inline Task appeared with the old canonical checkbox title. | | Reminders: Flag, subtask and extra list controls | NOT RETESTED | Round 1 Apple limitations were not checked again. | | Files: native mount, Unicode folder and filename | PASS | Native NetFS mount; NFD filename became NFC on the server. | | Files: copy, read, append, rename, move and delete | PASS | Native byte checks passed; deleted entries were absent in DAV listing. | | Files: 50 MB copy | PASS | Source, mounted read and independent DAV GET had identical SHA-256. | | Files: 30 files in three levels | PASS | Recursive byte comparison, rename and delete passed. | | Files: API folder create and rename to Mac | PASS | DAV MKCOL/MOVE returned 201; renamed folder was visible on the mount. | | Files: copy extended attributes with cp | FAIL #648 | Both copies returned exit 1. All 17 content bytes survived; attributes did not. The earlier zero-byte result was not reproduced. | | Files: Finder GUI metadata copy | CONTENT PASS, METADATA FAIL #648 | After copy completion, all 17 bytes matched. The extended attribute was absent. | | Files: volume name | KNOWN GAP #648 | Finder uses the User ID as the volume name. | | Notes: discovery, create, edit, move, delete and rich content | NOT EXPOSED #858 | No public IMAP route or staging IMAP listener with a valid certificate. | ## Verification and limits The setup helper passed saved-passkey sign-in for both test accounts and obtained a real App Password and profile. Setup and recovery browser flows also passed during preparation. Final syntax, format and whitespace checks passed. No Rust crate, route, background job or product UI changed, so crate clippy/tests, web gates, responsive screenshots and a hot-path benchmark do not apply to this change. The 50 MB check measures integrity, not performance. A single functional DAV rejection check covered stale revision and documented unsupported Calendar writes. It did not run a hostile-input campaign against staging. Server journal capture showed no ERROR or panic lines; it is not a complete HTTP status trace. No staging deployment or production change occurred. ## UX gaps No product UX gap was fixed by this test job. Findings are on #643, #647, #648, #858 and #940. The two observed losses of Task properties must block release. The Mac has notifications disabled for Reminders; the owner must enable them before testing notification delivery. No password prompt was needed for the final account installation. ## Decisions Use the server-generated profile without Notes after macOS rolled back the combined profile. Leave Notes untested until its edge is available. Keep the staging build unchanged so results refer to the owner's selected image. These are test choices. No product design choice was added. Mac screenshots and the full gate output are attached or quoted on #476. Raw non-secret test evidence remains in `artifacts/macinterop/staging-r2/`. Screenshots are not committed. ## Gate output (verbatim) ```text cargo fmt --check: exit 0; no output node --check tests/manual/apple-staging-setup.mjs: exit 0; no output git diff --check: exit 0; no output interop-admin saved passkey sign-in passed macinterop saved passkey sign-in passed Test User, App Password and profile ready; secrets saved privately. ``` ## Mac screenshots [Calendar before deletes](https://git.kayg.org/attachments/b5ae839d-5595-41ff-9f9d-64add05ac6f0) [Calendar after deleting one area](https://git.kayg.org/attachments/24e111ab-84ca-45cd-86af-797c25d36c4c) [Reminders Unicode batch and date-only Task](https://git.kayg.org/attachments/83d72b6d-290c-4837-ba6a-a4e3f07f8210) [Finder 50 MB file and Unicode filename](https://git.kayg.org/attachments/f3da7286-a298-4dd5-997f-adb5390f891a) The screenshots are from the real Mac. No product UI changed, so there is no responsive web screenshot set. Notifications remain disabled in macOS; enable them for a delivery test. The installed staging profile remains available; its private copy is preserved separately from later helper-generated profiles. The Mac lock and staging journal watch are released. `cargo clean` returned `Removed 1 file, 356B total`. The worktree is clean.
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
kayg/calternal#476
No description provided.