DAV fixture discovery exceeds its deadline after mixed API storms #1081

Open
opened 2026-10-05 02:47:03 +00:00 by kayg · 0 comments
Owner

Observed during merge round 9 (#1038), product d209662581, copied local debug server SHA-256 463ffe23a2ae1e3df5955fde0a4608d3b29f42e8ab2c2e88464bfd3ecae8854a.

The broad direct-backend API campaign (tests/adversarial/attack.py, through the standard throwaway fixture runner) accepted the 100-entry Journal fixture but did not discover its area Calendar collection within the existing 30-second deadline. The finding was:

 - DAV 100-href area discovery :: the imported area did not become a Calendar collection

No server crash or 5xx was observed. The same unchanged 100-resource expectation then passed in one focused ADVERSARIAL_DAV_ONLY=1 replay on the same product:

DAV 100-href Apple multiget: 18045 request bytes, 100 responses, 0.158s

The broad round ran directory, rename, tag, Task and DAV probes before this case. It also recorded 20 SLOW findings for Photos setup, Journal attachment writes and Calendar duplicates. Load is a possible cause of the fixture discovery timeout; this run does not establish it. The timeout is kept as a separate finding, rather than silently relabelled SLOW. There is no measured release baseline or data-loss evidence here.

Follow up: establish the Notes ingestion/Calendar collection state during the deadline, identify whether Index work is delayed or the fixture polling affects progress, and add a focused regression if a product defect is confirmed. Keep the existing status, resource-count and deadline expectations for owner review. No credentials or production data are part of the reproduction.

Observed during merge round 9 (#1038), product d209662581756d6050e62b5c566ac9a03379c4be, copied local debug server SHA-256 463ffe23a2ae1e3df5955fde0a4608d3b29f42e8ab2c2e88464bfd3ecae8854a. The broad direct-backend API campaign (`tests/adversarial/attack.py`, through the standard throwaway fixture runner) accepted the 100-entry Journal fixture but did not discover its area Calendar collection within the existing 30-second deadline. The finding was: ``` - DAV 100-href area discovery :: the imported area did not become a Calendar collection ``` No server crash or 5xx was observed. The same unchanged 100-resource expectation then passed in one focused `ADVERSARIAL_DAV_ONLY=1` replay on the same product: ``` DAV 100-href Apple multiget: 18045 request bytes, 100 responses, 0.158s ``` The broad round ran directory, rename, tag, Task and DAV probes before this case. It also recorded 20 SLOW findings for Photos setup, Journal attachment writes and Calendar duplicates. Load is a possible cause of the fixture discovery timeout; this run does not establish it. The timeout is kept as a separate finding, rather than silently relabelled SLOW. There is no measured release baseline or data-loss evidence here. Follow up: establish the Notes ingestion/Calendar collection state during the deadline, identify whether Index work is delayed or the fixture polling affects progress, and add a focused regression if a product defect is confirmed. Keep the existing status, resource-count and deadline expectations for owner review. No credentials or production data are part of the reproduction.
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#1081
No description provided.