Reduce DB work on cold Calendar activation

kayg commented

2026-10-10 20:07:17 +00:00

Owner

Evidence

The #1233 one-sample cold Mail→Calendar trace on the reduced 100-file fixture took 2,408.8 ms from trusted input to full paint. It recorded 21 requests and 683,866 response bytes. Calendar Server-Timing showed two range reads and two item reads:

range: 241.563 ms total, 220.935 ms DB
items: 189.060 ms total, 85.322 ms DB
range: 296.979 ms total, 269.313 ms DB
items: 198.555 ms total, 170.409 ms DB

The browser trace also shows substantial client-side Calendar activation work, so this issue tracks only the server query path. The request pairs may overlap; these durations are per-request server timings and do not prove a summed wall-clock dependency. The one-sample trace is diagnostic, not an A/B comparison. Trace and request waterfall are in the #1233 worktree at artifacts/tab-switch-1233-cold100-recheck/mail-calendar-cold-trace.json and mail-calendar-cold-network.json.

Request

Investigate why cold Calendar activation issues two range reads and two item reads, and reduce DB work on the critical path if confirmed. Add request-level timing coverage and compare five interleaved A/B pairs; require p50 and p95 to improve by at least 10% without another cell's p95 regressing by more than 10%.

## Evidence The #1233 one-sample cold Mail→Calendar trace on the reduced 100-file fixture took 2,408.8 ms from trusted input to full paint. It recorded 21 requests and 683,866 response bytes. Calendar Server-Timing showed two range reads and two item reads: - range: 241.563 ms total, 220.935 ms DB - items: 189.060 ms total, 85.322 ms DB - range: 296.979 ms total, 269.313 ms DB - items: 198.555 ms total, 170.409 ms DB The browser trace also shows substantial client-side Calendar activation work, so this issue tracks only the server query path. The request pairs may overlap; these durations are per-request server timings and do not prove a summed wall-clock dependency. The one-sample trace is diagnostic, not an A/B comparison. Trace and request waterfall are in the #1233 worktree at `artifacts/tab-switch-1233-cold100-recheck/mail-calendar-cold-trace.json` and `mail-calendar-cold-network.json`. ## Request Investigate why cold Calendar activation issues two range reads and two item reads, and reduce DB work on the critical path if confirmed. Add request-level timing coverage and compare five interleaved A/B pairs; require p50 and p95 to improve by at least 10% without another cell's p95 regressing by more than 10%.

kayg referenced this issue

2026-10-10 20:08:46 +00:00

Tabs: reduce warm Calendar to Files input-to-paint latency #1233

kayg commented

2026-10-10 23:43:10 +00:00

Author

Owner

Started work on branch job/calcold-1560 at base 0c712b98c164b6734d54f63485012bd1a11005b4 (origin/dev at job start). Issue baseline names 4ebeba0b8; the worktree already includes newer origin/dev commits.

Started work on branch `job/calcold-1560` at base `0c712b98c164b6734d54f63485012bd1a11005b4` (`origin/dev` at job start). Issue baseline names `4ebeba0b8`; the worktree already includes newer `origin/dev` commits.

kayg commented

2026-10-10 23:52:45 +00:00

Author

Owner

Finding: the Calendar range Event query is broader than its range index suggests. An SQLite EXPLAIN QUERY PLAN run on 1,000 recurring Event resources (with range_start and range_end NULL, as required when recurrence bounds are unknown) reported SEARCH e USING INDEX calendar_events_range (owner_id=? AND calendar_id=?), a correlated SEARCH candidate USING INDEX calendar_events_uid (owner_id=? AND calendar_id=? AND uid=?), and USE TEMP B-TREE FOR ORDER BY. The current query therefore visits every cached Event resource in each visible Calendar and sorts the candidates. Separately, URL subscription caches are fetched with one read_cache query per visible definition. I am measuring the request path next; this is source/plan evidence, not yet a timing conclusion.

Finding: the Calendar range Event query is broader than its range index suggests. An SQLite EXPLAIN QUERY PLAN run on 1,000 recurring Event resources (with `range_start` and `range_end` NULL, as required when recurrence bounds are unknown) reported `SEARCH e USING INDEX calendar_events_range (owner_id=? AND calendar_id=?)`, a correlated `SEARCH candidate USING INDEX calendar_events_uid (owner_id=? AND calendar_id=? AND uid=?)`, and `USE TEMP B-TREE FOR ORDER BY`. The current query therefore visits every cached Event resource in each visible Calendar and sorts the candidates. Separately, URL subscription caches are fetched with one `read_cache` query per visible definition. I am measuring the request path next; this is source/plan evidence, not yet a timing conclusion.

kayg commented

2026-10-11 00:41:12 +00:00

Author

Owner

Confirmed query-plan finding and fix in progress: the previous Calendar range SELECT scanned cached Events through calendar_events_range, ran a correlated same-UID EXISTS lookup, and sorted the broad candidate set. On a settled 1,000-Event fixture, EXPLAIN QUERY PLAN for the new direct-match CTE uses calendar_events_owner_window and expands sibling resources through calendar_events_uid. The query still applies the same stable ordering/cap and retains detached UID siblings.

Migration 7 adds only the index. A test creates the version 6 schema and 1,000 cached Events, applies migration 7, verifies all rows remain, and checks the three matching resources (two same-UID all-day siblings plus one timed Event). The Calendar crate gates passed: cargo fmt --check; cargo clippy -p calternal-plugin-calendar --all-targets -- -D warnings; and cargo test -p calternal-plugin-calendar (107 passed, 1 ignored; integration tests 5 passed).

Confirmed query-plan finding and fix in progress: the previous Calendar range SELECT scanned cached Events through `calendar_events_range`, ran a correlated same-UID EXISTS lookup, and sorted the broad candidate set. On a settled 1,000-Event fixture, `EXPLAIN QUERY PLAN` for the new direct-match CTE uses `calendar_events_owner_window` and expands sibling resources through `calendar_events_uid`. The query still applies the same stable ordering/cap and retains detached UID siblings. Migration 7 adds only the index. A test creates the version 6 schema and 1,000 cached Events, applies migration 7, verifies all rows remain, and checks the three matching resources (two same-UID all-day siblings plus one timed Event). The Calendar crate gates passed: `cargo fmt --check`; `cargo clippy -p calternal-plugin-calendar --all-targets -- -D warnings`; and `cargo test -p calternal-plugin-calendar` (107 passed, 1 ignored; integration tests 5 passed).

kayg commented

2026-10-11 00:52:17 +00:00

Author

Owner

Second confirmed DB-work finding: Calendar subscription projection called read_cache once inside the loop for each visible definition (up to the 64-feed Home limit). The range path now uses one owner-scoped id IN (...) read for all visible feed caches, and the subscriptions list uses a separate batched status-only projection so it does not fetch ICS bodies it never displays. A focused test checks missing IDs, cross-owner isolation, empty input, and the 64-item bound.

Added request-level coverage through the Calendar timing middleware for both /range and /items; both retain 200/JSON responses and report db;dur. Calendar gates: fmt clean, clippy clean, 109 passed/1 ignored plus 5 integration tests. Files gates: clippy clean, 281 passed/4 ignored plus 9 integration tests. Head: 448d2159c3.

Second confirmed DB-work finding: Calendar subscription projection called `read_cache` once inside the loop for each visible definition (up to the 64-feed Home limit). The range path now uses one owner-scoped `id IN (...)` read for all visible feed caches, and the subscriptions list uses a separate batched status-only projection so it does not fetch ICS bodies it never displays. A focused test checks missing IDs, cross-owner isolation, empty input, and the 64-item bound. Added request-level coverage through the Calendar timing middleware for both `/range` and `/items`; both retain 200/JSON responses and report `db;dur`. Calendar gates: fmt clean, clippy clean, 109 passed/1 ignored plus 5 integration tests. Files gates: clippy clean, 281 passed/4 ignored plus 9 integration tests. Head: 448d2159c31d71bf7a782f692375703bc88e296a.

kayg commented

2026-10-11 01:12:11 +00:00

Author

Owner

The query plan checks now cover both Calendar activation reads on realistic fixture data. The range plan uses calendar_events_owner_window for direct date matches and calendar_events_uid for sibling series; the Calendar Items plan uses files_index_calendar, the Task source index, photo indexes, and the Note indexes. Both outputs are captured by focused EXPLAIN QUERY PLAN tests.

The #1233 harness now has an issue-specific fixture with 30 daily CalDAV series and 10 URL subscriptions containing 50 more recurring series. It captures sanitized /calendar/range and /calendar/items request counts with each response's db;dur, plus a 20-request serial Calendar range p50/p95. No Calendar rendering component changed.

The query plan checks now cover both Calendar activation reads on realistic fixture data. The range plan uses `calendar_events_owner_window` for direct date matches and `calendar_events_uid` for sibling series; the Calendar Items plan uses `files_index_calendar`, the Task source index, photo indexes, and the Note indexes. Both outputs are captured by focused `EXPLAIN QUERY PLAN` tests. The #1233 harness now has an issue-specific fixture with 30 daily CalDAV series and 10 URL subscriptions containing 50 more recurring series. It captures sanitized `/calendar/range` and `/calendar/items` request counts with each response's `db;dur`, plus a 20-request serial Calendar range p50/p95. No Calendar rendering component changed.

kayg commented

2026-10-11 01:35:27 +00:00

Author

Owner

The first baseline fixture attempt exposed unrelated setup work: the inherited smoke seeder generated 30 Daily items per day, and the 4ebeba0b8 server remained in notes-upgrade-backfills for over 13 minutes while its process accumulated about 1.68 GB of writes. No activation sample was taken. I stopped that preparation and changed the issue-specific profile to seed one Daily item per day; the 30 CalDAV and 50 subscription recurring series remain unchanged, and the profile still asserts at least 1,000 projected Event instances before saving the fixture.

The first baseline fixture attempt exposed unrelated setup work: the inherited smoke seeder generated 30 Daily items per day, and the 4ebeba0b8 server remained in `notes-upgrade-backfills` for over 13 minutes while its process accumulated about 1.68 GB of writes. No activation sample was taken. I stopped that preparation and changed the issue-specific profile to seed one Daily item per day; the 30 CalDAV and 50 subscription recurring series remain unchanged, and the profile still asserts at least 1,000 projected Event instances before saving the fixture.

kayg commented

2026-10-11 01:55:32 +00:00

Author

Owner

The local fixture setup exposed unrelated Notes startup cost before any Calendar sample: the one-entry-per-day smoke Home still has 366 Journal Markdown files, and the server has spent about 18 minutes in notes-upgrade-backfills while writing over 850 MB. The earlier 30-entry-per-day setup was already aborted after about 13 minutes. I am reducing only the Calendar activation profile's seeded Journal date window; the CalDAV and URL-subscription recurrence fixture and its >=1,000 projected Event assertion remain unchanged. No timing sample has been recorded yet.

The local fixture setup exposed unrelated Notes startup cost before any Calendar sample: the one-entry-per-day smoke Home still has 366 Journal Markdown files, and the server has spent about 18 minutes in `notes-upgrade-backfills` while writing over 850 MB. The earlier 30-entry-per-day setup was already aborted after about 13 minutes. I am reducing only the Calendar activation profile's seeded Journal date window; the CalDAV and URL-subscription recurrence fixture and its >=1,000 projected Event assertion remain unchanged. No timing sample has been recorded yet.

kayg commented

2026-10-11 02:07:03 +00:00

Author

Owner

The first baseline Mail→Calendar sample completed and captured 2 /calendar/range plus 2 /calendar/items reads. The runner then continued into its inherited LinkNav intent profile and timed out waiting for .attachment-row, marking the combined report incomplete. That route is outside #1560, so I am rerunning the activation-only profile with --switch-only; the captured incomplete sample will not be used.

The first baseline Mail→Calendar sample completed and captured 2 `/calendar/range` plus 2 `/calendar/items` reads. The runner then continued into its inherited LinkNav intent profile and timed out waiting for `.attachment-row`, marking the combined report incomplete. That route is outside #1560, so I am rerunning the activation-only profile with `--switch-only`; the captured incomplete sample will not be used.

kayg commented

2026-10-11 02:24:25 +00:00

Author

Owner

The activation probe expanded 1,200 Event instances, but inspection of the fixture showed only 30 CalDAV source resources and 50 VEVENTs held in ten URL subscription caches. That did not exercise a 1,000-row CalDAV cache/index. I am extending the fixture with 1,000 dated CalDAV Event resources while retaining the 30 daily recurring series and ten subscriptions, then repeating the five interleaved pairs.

kayg commented

2026-10-11 02:53:43 +00:00

Author

Owner

The date-only request observer confirms the four Calendar reads use two distinct windows on the settled 1,030-source-Event fixture. The 7-day default Week preload requests range 2026-10-04..2026-10-11 and items 2026-10-05..2026-10-11; the grid's bounded six-week read-ahead requests range 2026-09-20..2026-11-01 and items 2026-09-21..2026-11-01. The windows differ, so same-key range-cache coalescing does not apply. One local diagnostic sample recorded DB times of 407/264 ms for the ranges and 398/256 ms for the items while host load was 4.89/5.63/6.46; this sample is diagnostic, not part of the final A/B aggregate. I am keeping the Calendar rendering callsites untouched and measuring the server query/index and batched subscription changes against this same request mix.

The date-only request observer confirms the four Calendar reads use two distinct windows on the settled 1,030-source-Event fixture. The 7-day default Week preload requests range `2026-10-04..2026-10-11` and items `2026-10-05..2026-10-11`; the grid's bounded six-week read-ahead requests range `2026-09-20..2026-11-01` and items `2026-09-21..2026-11-01`. The windows differ, so same-key range-cache coalescing does not apply. One local diagnostic sample recorded DB times of 407/264 ms for the ranges and 398/256 ms for the items while host load was 4.89/5.63/6.46; this sample is diagnostic, not part of the final A/B aggregate. I am keeping the Calendar rendering callsites untouched and measuring the server query/index and batched subscription changes against this same request mix.

kayg commented

2026-10-11 02:57:14 +00:00

Author

Owner

I invalidated the initial A/B samples after verifying server_source_commit: the staged candidate binary reports 7ea0644a, while the query-window index and batched subscription reads landed in 449c1495 and 448d2159. I am building a matching candidate server and will rerun all five interleaved pairs with the same measured browser cell. The earlier sample numbers are diagnostic only and will not be used in the final comparison.

I invalidated the initial A/B samples after verifying `server_source_commit`: the staged candidate binary reports `7ea0644a`, while the query-window index and batched subscription reads landed in `449c1495` and `448d2159`. I am building a matching candidate server and will rerun all five interleaved pairs with the same measured browser cell. The earlier sample numbers are diagnostic only and will not be used in the final comparison.

kayg referenced this issue from a commit

2026-10-11 03:21:50 +00:00

Record Calendar request date windows in activation profile

kayg referenced this issue from a commit

2026-10-11 03:21:50 +00:00

Profile Calendar range burst cost and server memory

kayg commented

2026-10-11 04:32:38 +00:00

Author

Owner

The server crate gate exposed an upgrade inventory expectation that must track the new migration. production_round_9_schema_upgrades_once_with_original_receipts applied both Calendar receipts 0006 and 0007 from the 4eb-derived fixture, while its expected pending list contained only 0006. I added 0007 to that inventory and documented that #1560 adds it.

The same full server test run also had a live-app startup timeout: nested startup_serves_http_while_upgrade_backfills_wait did not finish its background backfills within 100.86 seconds. The other server tests completed; I am rerunning the focused migration test and will report this slow timeout separately.

The server crate gate exposed an upgrade inventory expectation that must track the new migration. `production_round_9_schema_upgrades_once_with_original_receipts` applied both Calendar receipts 0006 and 0007 from the 4eb-derived fixture, while its expected pending list contained only 0006. I added 0007 to that inventory and documented that #1560 adds it. The same full server test run also had a live-app startup timeout: nested `startup_serves_http_while_upgrade_backfills_wait` did not finish its background backfills within 100.86 seconds. The other server tests completed; I am rerunning the focused migration test and will report this slow timeout separately.

kayg commented

2026-10-11 05:22:25 +00:00

Author

Owner

The first perf-VM A/B attempt did not produce samples. Startup waited 1,500,000 ms and then reported status=200, state=migrating, phase=notes-upgrade-backfills; the default fixture included 5,000 Notes, 2,000 Tasks, and 20,000 Money transactions. I stopped the run before the perf-run cap, confirmed the lock was free, and narrowed only the unrelated Home seed via --smoke. The rerun keeps --fixture-years 3, the 1,000+ Event Calendar fixture assertion, the same baseline/candidate builds, and five interleaved pairs.

The first perf-VM A/B attempt did not produce samples. Startup waited 1,500,000 ms and then reported `status=200`, `state=migrating`, `phase=notes-upgrade-backfills`; the default fixture included 5,000 Notes, 2,000 Tasks, and 20,000 Money transactions. I stopped the run before the perf-run cap, confirmed the lock was free, and narrowed only the unrelated Home seed via `--smoke`. The rerun keeps `--fixture-years 3`, the 1,000+ Event Calendar fixture assertion, the same baseline/candidate builds, and five interleaved pairs.

kayg commented

2026-10-11 06:19:21 +00:00

Author

Owner

Completed

Branch: job/calcold-1560
Base: 4ebeba0b8e13b06223bc2b24ee7a398a0933bda0
Head: 6f686af4107151874382767ef831fb2181dc3faa

Findings and changes

Cold Week activation preloaded 2026-10-04..2026-10-11, while the mounted grid requested 2026-09-20..2026-11-01. Exact-key cache reuse could not join those reads. This caused two range requests and two Items requests. Week preload now uses the grid's six-week window.

Calendar range SQL now selects direct overlaps through separate timed/all-day arms, then expands matching recurrence UIDs through their index. Migration 0007_event_calendar_window.sql adds the owner/calendar/all-day/range index. Subscription cache and status reads use bounded batches. The production upgrade inventory and populated version-6 migration test cover upgrade from the 4ebeba0b8 schema. Request timing and query-plan coverage were added.

Perf VM A/B

Five interleaved pairs ran on perf-test-69-63 against the same settled snapshot. The fixture had 1,201 projected Event instances in the probe window, 10 subscriptions, 30 recurring CalDAV Events, 1,000 one-off CalDAV Events, and 50 recurring subscription Events. The VM was HDD-qualified. Lock-start load average was 2.36, 3.59, 3.40.

Cold Mail→Calendar input-to-full-paint: p50 2679.1 → 1841.6 ms (-31.3%); p95 3298.1 → 2006.9 ms (-39.1%).
Isolated serial Calendar range DB timing (median of five run summaries): p50 5.92 → 4.37 ms (-26.2%); p95 41.05 → 9.90 ms (-75.9%).
Range burst DB p95: 236.95 → 228.21 ms; no p95 regression.
Per activation, range and Items requests fell from 2 + 2 to 1 + 1. Captured activation DB totals improved p50/p95 by 20.5% / 17.3%.

The 4eb source query used a correlated EXISTS range predicate. The candidate EXPLAIN plan uses calendar_events_owner_window for the timed/all-day overlap arms and calendar_events_uid for sibling expansion. The Items plan uses its date and identity indexes and keeps one bounded UNION ALL query.

Perf results are recorded in docs/perf/baseline.json. The first full-size seed hit the harness's 1,500,000 ms startup limit at phase=notes-upgrade-backfills; the successful run used --smoke only for unrelated Home data and kept the three-year Calendar fixture and 1,000+ Event assertion.

Expected activation DB work is one bounded visible-Event range query plus one bounded Activity union query. Event work scales with visible calendars and overlapping Event resources; item work stays date-bounded and indexed.

Gates

cargo fmt --check: exit 0, no output.
cargo clippy -p calternal-plugin-calendar --all-targets -- -D warnings, cargo clippy -p calternal-plugin-files --all-targets -- -D warnings, and cargo clippy -p calternal-server --all-targets -- -D warnings: all exited 0 with no warnings.
cargo test -p calternal-plugin-calendar: 110 passed; 0 failed; 1 ignored; cache integration 2 passed; protocol integration 3 passed.
cargo test -p calternal-plugin-files: 281 passed; 0 failed; 4 ignored; jdrev2 integration 9 passed.
cargo test -p calternal-server -- --test-threads=4: 277 passed; 0 failed; 12 ignored; tests/perf_guards.rs and tests/private_index_permissions.rs each 1 passed; 0 failed. The initial default-parallel run hit an unrelated live-app backfill timeout; the focused upgrade test and full four-thread rerun passed.
bun run check: perf-lint: PASS; 0 violations; 22080 scoped exceptions; svelte-check found 0 errors and 0 warnings.
bun run test --maxWorkers=2: Test Files 318 passed (318); Tests 2317 passed (2317); Duration 248.51s (environment 29%, transform 23%, import 22%, tests 20%, setup 5%).
cargo clean: Removed 30206 files, 23.3GiB total. apps/web/build was deleted.

Decisions and known gaps

Used the existing smoke seed for Notes, Tasks, Money and Files because their full default import blocked Calendar fixture readiness. Calendar still used real API data and 1,201 in-window Event instances.
The five-pair p95 for activation is the maximum of five samples. Serial and burst range p50/p95 values are medians of the five run-level summaries.
Baseline activation had two Items responses, but only one per sample exposed a parseable db;dur metric. The recorded baseline activation DB total is therefore a lower bound; the request counts and date windows include both responses.
A separate baseline EXPLAIN was not captured. Another perf job acquired the lock immediately after these pairs, so the queued read-only capture was canceled. Candidate EXPLAIN output is covered by the query-plan tests.
tests/adversarial/run.sh was not run in this job per the merge-round verification policy. The merge round should run it against a real server to prove Calendar range/Items robustness, authorization, and concurrency behavior.

No UI rendering changed. No screenshots were required for the fetch-only change.

## Completed Branch: `job/calcold-1560` Base: `4ebeba0b8e13b06223bc2b24ee7a398a0933bda0` Head: `6f686af4107151874382767ef831fb2181dc3faa` ## Findings and changes Cold Week activation preloaded `2026-10-04..2026-10-11`, while the mounted grid requested `2026-09-20..2026-11-01`. Exact-key cache reuse could not join those reads. This caused two range requests and two Items requests. Week preload now uses the grid's six-week window. Calendar range SQL now selects direct overlaps through separate timed/all-day arms, then expands matching recurrence UIDs through their index. Migration `0007_event_calendar_window.sql` adds the owner/calendar/all-day/range index. Subscription cache and status reads use bounded batches. The production upgrade inventory and populated version-6 migration test cover upgrade from the `4ebeba0b8` schema. Request timing and query-plan coverage were added. ## Perf VM A/B Five interleaved pairs ran on `perf-test-69-63` against the same settled snapshot. The fixture had 1,201 projected Event instances in the probe window, 10 subscriptions, 30 recurring CalDAV Events, 1,000 one-off CalDAV Events, and 50 recurring subscription Events. The VM was HDD-qualified. Lock-start load average was `2.36, 3.59, 3.40`. - Cold Mail→Calendar input-to-full-paint: p50 `2679.1 → 1841.6 ms` (-31.3%); p95 `3298.1 → 2006.9 ms` (-39.1%). - Isolated serial Calendar range DB timing (median of five run summaries): p50 `5.92 → 4.37 ms` (-26.2%); p95 `41.05 → 9.90 ms` (-75.9%). - Range burst DB p95: `236.95 → 228.21 ms`; no p95 regression. - Per activation, range and Items requests fell from `2 + 2` to `1 + 1`. Captured activation DB totals improved p50/p95 by `20.5% / 17.3%`. The 4eb source query used a correlated `EXISTS` range predicate. The candidate EXPLAIN plan uses `calendar_events_owner_window` for the timed/all-day overlap arms and `calendar_events_uid` for sibling expansion. The Items plan uses its date and identity indexes and keeps one bounded `UNION ALL` query. Perf results are recorded in `docs/perf/baseline.json`. The first full-size seed hit the harness's 1,500,000 ms startup limit at `phase=notes-upgrade-backfills`; the successful run used `--smoke` only for unrelated Home data and kept the three-year Calendar fixture and 1,000+ Event assertion. Expected activation DB work is one bounded visible-Event range query plus one bounded Activity union query. Event work scales with visible calendars and overlapping Event resources; item work stays date-bounded and indexed. ## Gates - `cargo fmt --check`: exit 0, no output. - `cargo clippy -p calternal-plugin-calendar --all-targets -- -D warnings`, `cargo clippy -p calternal-plugin-files --all-targets -- -D warnings`, and `cargo clippy -p calternal-server --all-targets -- -D warnings`: all exited 0 with no warnings. - `cargo test -p calternal-plugin-calendar`: `110 passed; 0 failed; 1 ignored`; cache integration `2 passed`; protocol integration `3 passed`. - `cargo test -p calternal-plugin-files`: `281 passed; 0 failed; 4 ignored`; `jdrev2` integration `9 passed`. - `cargo test -p calternal-server -- --test-threads=4`: `277 passed; 0 failed; 12 ignored`; `tests/perf_guards.rs` and `tests/private_index_permissions.rs` each `1 passed; 0 failed`. The initial default-parallel run hit an unrelated live-app backfill timeout; the focused upgrade test and full four-thread rerun passed. - `bun run check`: `perf-lint: PASS; 0 violations; 22080 scoped exceptions`; `svelte-check found 0 errors and 0 warnings`. - `bun run test --maxWorkers=2`: `Test Files 318 passed (318)`; `Tests 2317 passed (2317)`; `Duration 248.51s (environment 29%, transform 23%, import 22%, tests 20%, setup 5%)`. - `cargo clean`: `Removed 30206 files, 23.3GiB total`. `apps/web/build` was deleted. ## Decisions and known gaps - Used the existing smoke seed for Notes, Tasks, Money and Files because their full default import blocked Calendar fixture readiness. Calendar still used real API data and 1,201 in-window Event instances. - The five-pair p95 for activation is the maximum of five samples. Serial and burst range p50/p95 values are medians of the five run-level summaries. - Baseline activation had two Items responses, but only one per sample exposed a parseable `db;dur` metric. The recorded baseline activation DB total is therefore a lower bound; the request counts and date windows include both responses. - A separate baseline EXPLAIN was not captured. Another perf job acquired the lock immediately after these pairs, so the queued read-only capture was canceled. Candidate EXPLAIN output is covered by the query-plan tests. - `tests/adversarial/run.sh` was not run in this job per the merge-round verification policy. The merge round should run it against a real server to prove Calendar range/Items robustness, authorization, and concurrency behavior. No UI rendering changed. No screenshots were required for the fetch-only change.

kayg commented

2026-10-11 20:08:37 +00:00

Author

Owner

Deployed to calternal.cloud in merge round 40 (build c0f8da461, 01:38 IST 2026-10-12). Health state ok, /readyz 200, served-page check passed. Pre-deploy backup taken.

Deployed to calternal.cloud in merge round 40 (build c0f8da461, 01:38 IST 2026-10-12). Health state ok, /readyz 200, served-page check passed. Pre-deploy backup taken.

kayg closed this issue

2026-10-11 20:08:37 +00:00

Rows
Columns

Reduce DB work on cold Calendar activation #1560

Evidence

Request

Completed

Findings and changes

Perf VM A/B

Gates

Decisions and known gaps