Investigate bookmark capture timeouts during concurrent writes

kayg commented

2026-09-27 08:49:35 +00:00

Owner

Evidence

The live adversarial run against the merged dev branch sent 16 concurrent POST /api/v1/notes/bookmarks requests. The probe uses a 10-second client timeout. It received 11 responses with status 201; 5 requests returned no response (-1), and the 11 responses contained 11 unique IDs. The server stayed alive through the end of the run.

The run took place on the shared build host while other worktrees were running browser and API probes. The probe reported this as a non-SLOW finding because these requests exceeded its timeout. This issue records the tail-latency result for follow-up under controlled host load. It does not establish a server crash or an HTTP 5xx.

Suggested follow-up

Repeat the 16-request bookmark capture storm on an otherwise idle local server. Record response times and whether requests that time out still create their Notes. If isolated runs still exceed the timeout, reduce write-path contention while preserving the per-user serialization and filesystem safety rules.

## Evidence The live adversarial run against the merged `dev` branch sent 16 concurrent `POST /api/v1/notes/bookmarks` requests. The probe uses a 10-second client timeout. It received 11 responses with status 201; 5 requests returned no response (`-1`), and the 11 responses contained 11 unique IDs. The server stayed alive through the end of the run. The run took place on the shared build host while other worktrees were running browser and API probes. The probe reported this as a non-`SLOW` finding because these requests exceeded its timeout. This issue records the tail-latency result for follow-up under controlled host load. It does not establish a server crash or an HTTP 5xx. ## Suggested follow-up Repeat the 16-request bookmark capture storm on an otherwise idle local server. Record response times and whether requests that time out still create their Notes. If isolated runs still exceed the timeout, reduce write-path contention while preserving the per-user serialization and filesystem safety rules.

kayg referenced this issue

2026-09-27 09:26:08 +00:00

Date and time formats: one formatter, Settings choice, default = system locale; fix the calendar preview header #179

kayg commented

2026-09-27 11:30:05 +00:00

Author

Owner

This worktree's one-round adversarial run also reproduced the concurrent bookmark capture timeout on the production server: 16 concurrent requests to POST /api/v1/notes/bookmarks returned 12 201 responses and 4 client timeouts (-1), with 12 distinct IDs. The server remained live, and the timeout is consistent with this issue's shared-host load finding. Full log: target/tmp/phone-chrome-adversarial-retry.log in the phone-chrome worktree.

This worktree's one-round adversarial run also reproduced the concurrent bookmark capture timeout on the production server: 16 concurrent requests to `POST /api/v1/notes/bookmarks` returned 12 `201` responses and 4 client timeouts (`-1`), with 12 distinct IDs. The server remained live, and the timeout is consistent with this issue's shared-host load finding. Full log: `target/tmp/phone-chrome-adversarial-retry.log` in the phone-chrome worktree.

kayg referenced this issue

2026-09-27 12:36:49 +00:00

Phone chrome: sticky sheet handle + progressive-blur section header; contextual bars replace the tab bar #219

kayg commented

2026-09-27 17:59:08 +00:00

Author

Owner

New evidence from #219's required adversarial round at merge head 3025699104e0b57ec2275edd5fee00b5374f3d9d: the 16-request bookmark capture storm returned 3 201, 12 429, and 1 client timeout (-1). The successful responses had distinct IDs (the probe reported no ID-collision finding), and the server was alive at the end. This reproduces the concurrent timeout tracked here; the other 48 findings in that first-round summary were marked SLOW.

New evidence from #219's required adversarial round at merge head `3025699104e0b57ec2275edd5fee00b5374f3d9d`: the 16-request bookmark capture storm returned 3 `201`, 12 `429`, and 1 client timeout (`-1`). The successful responses had distinct IDs (the probe reported no ID-collision finding), and the server was alive at the end. This reproduces the concurrent timeout tracked here; the other 48 findings in that first-round summary were marked SLOW.

kayg commented

2026-09-27 18:00:17 +00:00

Author

Owner

Additional evidence from #219's adversarial round at merge head 3025699104e0b57ec2275edd5fee00b5374f3d9d: this run's 16-request bookmark capture storm returned 3 201, 12 429, and 1 client timeout (-1). The successful responses had distinct IDs (the probe emitted no ID-collision finding), and the server was alive at the end. The first-round summary had 49 findings: 48 SLOW observations and this non-SLOW timeout. This reproduces the concurrent timeout tracked here.

Additional evidence from #219's adversarial round at merge head `3025699104e0b57ec2275edd5fee00b5374f3d9d`: this run's 16-request bookmark capture storm returned 3 `201`, 12 `429`, and 1 client timeout (`-1`). The successful responses had distinct IDs (the probe emitted no ID-collision finding), and the server was alive at the end. The first-round summary had 49 findings: 48 SLOW observations and this non-SLOW timeout. This reproduces the concurrent timeout tracked here.

kayg referenced this issue

2026-09-27 18:42:17 +00:00

Phone chrome: sticky sheet handle + progressive-blur section header; contextual bars replace the tab bar #219

kayg referenced this issue

2026-10-02 17:26:01 +00:00

Investigate bookmark capture timeouts under write concurrency #154

kayg referenced this issue

2026-10-02 17:26:02 +00:00

Bookmark capture and site search time out under concurrent load #177

kayg commented

2026-10-02 17:26:03 +00:00

Author

Owner

Duplicate run to #154 and the bookmark-capture part of #177: each reports 16 concurrent POST /api/v1/notes/bookmarks requests with a 10-second client timeout, some 201 responses and the rest without a response. The server stayed alive and the runs had shared-host load. Recommend linking this run to #177 with #154 as repeated capture evidence.