Adversarial: Journal and calendar writes time out under load

kayg commented

2026-09-27 20:32:55 +00:00

Owner

A single time-boxed adversarial run against the merged dev build found API no-response and consistency failures during concurrent workload. The run was capped at 45 minutes. The worktree host also had concurrent builds in other worktrees, so the root cause is not established; most of the 335 reported entries were SLOW latency markers.

Non-SLOW evidence:

DAV initial sync returned no response within the probe's 30-second request timeout, so the expected sync token was missing.
Calendar Event-from-Note and Event-from-Log requests timed out. A later recurring-log occurrence also timed out; the follow-up check found the same event identity for two occurrences.
In a 24-request PATCH storm against one Journal entry, 16 requests timed out after 30 seconds and the other 8 returned 412 after 25.7 seconds. The probe expected one 200 and 23 412 responses.
Journal Note child attachment, Journal delete fixture creation, template create, oversized template, Reminders collection discovery, and Reminders incremental sync also had 30-second no-response results. The created VTODO was then absent from incremental sync.
During a later file feed/rename storm, the feed proxy returned 502 local adversarial server is unavailable; subsequent isolation requests got connection refused. The harness then hit its 45-minute timeout while in the follow-up phase.

Please investigate write contention, timeout behavior, and identity consistency under mixed load. The single run was not repeated.

A single time-boxed adversarial run against the merged dev build found API no-response and consistency failures during concurrent workload. The run was capped at 45 minutes. The worktree host also had concurrent builds in other worktrees, so the root cause is not established; most of the 335 reported entries were SLOW latency markers. Non-SLOW evidence: - DAV initial sync returned no response within the probe's 30-second request timeout, so the expected sync token was missing. - Calendar Event-from-Note and Event-from-Log requests timed out. A later recurring-log occurrence also timed out; the follow-up check found the same event identity for two occurrences. - In a 24-request PATCH storm against one Journal entry, 16 requests timed out after 30 seconds and the other 8 returned 412 after 25.7 seconds. The probe expected one 200 and 23 412 responses. - Journal Note child attachment, Journal delete fixture creation, template create, oversized template, Reminders collection discovery, and Reminders incremental sync also had 30-second no-response results. The created VTODO was then absent from incremental sync. - During a later file feed/rename storm, the feed proxy returned 502 `local adversarial server is unavailable`; subsequent isolation requests got connection refused. The harness then hit its 45-minute timeout while in the follow-up phase. Please investigate write contention, timeout behavior, and identity consistency under mixed load. The single run was not repeated.

kayg referenced this issue

2026-09-27 20:34:15 +00:00

Block actions: hover controls, make-note (→), block reminders with quiet hours, phone capsule bar (DESIGN §42) #191

kayg commented

2026-09-27 20:49:19 +00:00

Author

Owner

One-time real-server adversarial round on job/index-order after merge dev at 418fcdfce8: POST /api/v1/calendar/events/from-log timed out (NO RESPONSE (b'timed out')) after creating a Journal Log. The surrounding Calendar Event and Journal requests also recorded SLOW responses under shared-host load. This evidence is from tests/adversarial/attack.py; the runner continued after the timeout.

One-time real-server adversarial round on job/index-order after merge dev at 418fcdfce8fc1300eddb71fc6e1301d5afdedece: `POST /api/v1/calendar/events/from-log` timed out (`NO RESPONSE (b'timed out')`) after creating a Journal Log. The surrounding Calendar Event and Journal requests also recorded SLOW responses under shared-host load. This evidence is from tests/adversarial/attack.py; the runner continued after the timeout.

kayg referenced this issue

2026-09-27 21:11:21 +00:00

BUG: menus inside Settings/overlays have no blur (nested backdrop root); two rows highlighted #246

kayg referenced this issue

2026-09-27 21:14:52 +00:00

BUG: menus inside Settings/overlays have no blur (nested backdrop root); two rows highlighted #246

kayg referenced this issue

2026-09-27 21:21:07 +00:00

BUG: menus inside Settings/overlays have no blur (nested backdrop root); two rows highlighted #246

kayg referenced this issue

2026-09-27 21:57:37 +00:00

DATA: Files Index lags storage after concurrent upload + rename (repaired only by a later listing) #259

kayg referenced this issue

2026-09-27 22:14:07 +00:00

BUG: menus inside Settings/overlays have no blur (nested backdrop root); two rows highlighted #246

kayg referenced this issue

2026-09-28 11:01:23 +00:00

Adversarial attack2-only run uses deleted users and skips restart coordination #285

kayg commented

2026-09-28 11:47:52 +00:00

Author

Owner

Additional evidence from the single-pills adversarial run at head 46497b6a7c03eb02a7cbbbfac3f36b563c906af7: attack.py reported calendar Event from Log: NO RESPONSE (timed out). The preceding Event-from-Note and linked Log creates returned 201, with SLOW timings; no cause is established. Other builds and adversarial runners were active on the shared host. The run is still in progress.

Additional evidence from the single-pills adversarial run at head `46497b6a7c03eb02a7cbbbfac3f36b563c906af7`: `attack.py` reported `calendar Event from Log: NO RESPONSE (timed out)`. The preceding Event-from-Note and linked Log creates returned 201, with SLOW timings; no cause is established. Other builds and adversarial runners were active on the shared host. The run is still in progress.

kayg commented

2026-09-28 11:48:52 +00:00

Author

Owner

The same in-progress run also reported calendar Log this occurrence 0 first write: NO RESPONSE (timed out). The second occurrence write and retry returned 201 and 200, respectively, with SLOW timings. The event-from-Log request and the first occurrence write are distinct no-response observations from this run.

The same in-progress run also reported `calendar Log this occurrence 0 first write: NO RESPONSE (timed out)`. The second occurrence write and retry returned 201 and 200, respectively, with SLOW timings. The event-from-Log request and the first occurrence write are distinct no-response observations from this run.

kayg referenced this issue

2026-09-28 13:04:18 +00:00

UI: every lone icon button is a pill-in-a-pill (shared single PillGroup) — sidebar toggle first, then hunt all instances #319

kayg commented

2026-09-30 22:48:57 +00:00

Author

Owner

The round-3 API-only adversarial run recorded these non-SLOW results during its mixed API campaign:

The floating-time DAV PUT and Journal DELETE with a stale condition timed out at the probe's client timeout.
Reminders collection discovery timed out and the child collection was not found.
The Reminders completion PUT returned 201 after 29.5 s, but the following GET returned the item without its completed state.

The server was alive at the end. Local load average during the run was 23.46 / 26.74 / 27.64, and many other route calls took 15–29 s and were marked SLOW. This was one time-boxed run; I did not repeat it.

The round-3 API-only adversarial run recorded these non-SLOW results during its mixed API campaign: - The floating-time DAV PUT and Journal DELETE with a stale condition timed out at the probe's client timeout. - Reminders collection discovery timed out and the child collection was not found. - The Reminders completion PUT returned 201 after 29.5 s, but the following GET returned the item without its completed state. The server was alive at the end. Local load average during the run was 23.46 / 26.74 / 27.64, and many other route calls took 15–29 s and were marked SLOW. This was one time-boxed run; I did not repeat it.

kayg referenced this issue

2026-09-30 23:05:18 +00:00

Log attachments: deleted file still shown, attachments not live, batch send not live, Log order, raw camera names #427

kayg referenced this issue

2026-10-02 17:35:52 +00:00

Investigate Calendar Event from Log timeout under shared load #250

kayg commented

2026-10-02 17:35:58 +00:00

Author

Owner

Partial duplicate symptom with #250: both report Calendar Event-from-Log creation timing out at the 30-second client deadline during a shared-host adversarial run. This issue also reports a recurring occurrence identity mismatch and unrelated DAV, Journal and file-feed failures. Recommend linking only the Event-from-Log observation to #250 and keeping the other findings separate.

kayg referenced this issue

2026-10-02 17:42:29 +00:00

Audit: open issue hygiene (duplicates, already fixed, stale) #866

kayg commented

2026-10-03 09:31:42 +00:00

Author

Owner

Merge-round 7a follow-up on head 516faaa698. In the full adversarial run against the release server, the 20-request Calendar Journal duplicate storm returned 13 HTTP 201 responses and 7 client timeouts (requests 12–14 and 16–19). The probe then reported fewer than the expected 20 distinct returned IDs; this path did not read back persisted Journal state, so the timeouts do not establish data loss. The same run's 24-request Journal PATCH storm returned the expected 412 conflicts for its late requests, all marked SLOW at 26.1s. The server log showed SQLx pool waits up to 7.7s during the later phase; host load was above 40. This is another shared-load reproduction of the open write-timeout finding.

Merge-round 7a follow-up on head 516faaa698570bdb468626cf6cd75d9c81b33ac2. In the full adversarial run against the release server, the 20-request Calendar Journal duplicate storm returned 13 HTTP 201 responses and 7 client timeouts (requests 12–14 and 16–19). The probe then reported fewer than the expected 20 distinct returned IDs; this path did not read back persisted Journal state, so the timeouts do not establish data loss. The same run's 24-request Journal PATCH storm returned the expected 412 conflicts for its late requests, all marked SLOW at 26.1s. The server log showed SQLx pool waits up to 7.7s during the later phase; host load was above 40. This is another shared-load reproduction of the open write-timeout finding.

kayg referenced this issue

2026-10-03 12:56:40 +00:00

Issue hygiene sweep 2026-10-03 #1008

Rows
Columns

Adversarial: Journal and calendar writes time out under load #267