Adversarial API round found non-SLOW tag, DAV and timeout mismatches #568

Open
opened 2026-10-01 03:09:01 +00:00 by kayg · 3 comments
Owner

One focused ADVERSARIAL_API_ONLY=1 ADVERSARIAL_MCP_ONLY=1 round from tests/adversarial/run.sh on job/floating-sheet at e531cbf03a5606ff5b9658d6813eb67600ac37c7 after merging origin/dev returned non-SLOW findings. The temporary local server stayed alive at the end. SLOW-tagged latency results are omitted here per the owner rule.

Findings from the runner output:

  • Tag rename across sources returned 409 instead of 200. Tag reconcile after source repair and after XMP repair returned 409 instead of 204. Tag rebuild found two owners with tags, returned 409 instead of 204, and reported a source rebuild mismatch.
  • Task storm requests 3 and 11 timed out with no response instead of returning 201.
  • The DAV sibling edit race timed out for both requests instead of returning one 204 and one 412.
  • DAV Files credential setup returned 403 Access denied instead of 200.
  • A well-formed DAV Journal alarm returned 204 instead of 201.
  • DAV cross-date move returned 412 instead of 204 with a new ETag. DAV delete returned 412 instead of 204.
  • Reminders VTODO create timed out instead of returning 201 with an ETag.

The server remained alive, the search storm had zero failures, the mkdir storm created 200 items with zero errors, the rename race had one success and zero errors, and the Photos upload/content burst returned success statuses but was SLOW. The MCP Inspector exact-tool-set mismatch is filed separately as #564. Existing test expectations were not changed.

Please review whether the 409/status mismatches are expected under the concurrent workload and address the remaining non-SLOW results with focused regressions.

One focused `ADVERSARIAL_API_ONLY=1 ADVERSARIAL_MCP_ONLY=1` round from `tests/adversarial/run.sh` on `job/floating-sheet` at `e531cbf03a5606ff5b9658d6813eb67600ac37c7` after merging `origin/dev` returned non-SLOW findings. The temporary local server stayed alive at the end. SLOW-tagged latency results are omitted here per the owner rule. Findings from the runner output: - Tag rename across sources returned 409 instead of 200. Tag reconcile after source repair and after XMP repair returned 409 instead of 204. Tag rebuild found two owners with tags, returned 409 instead of 204, and reported a source rebuild mismatch. - Task storm requests 3 and 11 timed out with no response instead of returning 201. - The DAV sibling edit race timed out for both requests instead of returning one 204 and one 412. - DAV Files credential setup returned 403 `Access denied` instead of 200. - A well-formed DAV Journal alarm returned 204 instead of 201. - DAV cross-date move returned 412 instead of 204 with a new ETag. DAV delete returned 412 instead of 204. - Reminders VTODO create timed out instead of returning 201 with an ETag. The server remained alive, the search storm had zero failures, the mkdir storm created 200 items with zero errors, the rename race had one success and zero errors, and the Photos upload/content burst returned success statuses but was SLOW. The MCP Inspector exact-tool-set mismatch is filed separately as #564. Existing test expectations were not changed. Please review whether the 409/status mismatches are expected under the concurrent workload and address the remaining non-SLOW results with focused regressions.
Author
Owner

Evidence from this job's one local API-only adversarial round against the merged branch. The command used the prebuilt local server and a 20-minute time limit. It ended with timeout exit 124 during the Photos tag setup upload campaign.

Non-SLOW mismatches before timeout:

  • Appearance probe: appearance Auto default: new User unexpectedly has saved scheme {'mode': 'system'}.
  • Tag probe: rename across sources expected 200, got 409; reconcile after source repair expected 204, got 409; reconcile after XMP repair expected 204, got 409; rebuild expected 204, got 409 and reported source rebuild mismatch: [].
  • DAV Files credential setup expected 200, got 403 with {"code":"forbidden","message":"Access denied"}.
  • DAV Journal accepted a well-formed alarm with 204; the probe expected 201.

Hostile-byte probe completed with zero findings. It did not get a media thumbnail within its 10-second wait, so that response check was skipped. The other timings labelled SLOW were left as load-only findings. No production host was used.

Evidence from this job's one local API-only adversarial round against the merged branch. The command used the prebuilt local server and a 20-minute time limit. It ended with timeout exit 124 during the Photos tag setup upload campaign. Non-SLOW mismatches before timeout: - Appearance probe: appearance Auto default: new User unexpectedly has saved scheme {'mode': 'system'}. - Tag probe: rename across sources expected 200, got 409; reconcile after source repair expected 204, got 409; reconcile after XMP repair expected 204, got 409; rebuild expected 204, got 409 and reported source rebuild mismatch: []. - DAV Files credential setup expected 200, got 403 with {"code":"forbidden","message":"Access denied"}. - DAV Journal accepted a well-formed alarm with 204; the probe expected 201. Hostile-byte probe completed with zero findings. It did not get a media thumbnail within its 10-second wait, so that response check was skipped. The other timings labelled SLOW were left as load-only findings. No production host was used.
Author
Owner

Round 3 follow-up: the non-SLOW findings in this campaign repeat the tag and DAV mismatches already tracked here. The run used ADVERSARIAL_API_ONLY=1 on job/tasks-mode at f620390c724ee08540d38b0ba69c3d12225fc1e4 on 2026-10-01, against a fresh local server.

  • Valid tag rename travel → journey returned 409 (probe expects 200).
  • Tag reconcile after restoring malformed folder metadata and malformed XMP each returned 409 (probe expects 204). Rebuild after deleting the tag Index rows returned 409 and the source listing was empty.
  • The well-formed Journal alarm probe returned 204 instead of 201. The subsequent DAV cross-date move and delete returned 412 instead of 204. Issue #557 already records that the Journal probe may be using a stale expectation/ETag; these statuses remain unchanged in the probe.

No Task storm request timed out in this run. The single-request Task create p50 was 1.904 s and the storm's SLOW threshold was 47.60 s. The server remained alive; the search storm had zero failures, mkdir created 200 items with zero errors, and the rename race had one success and zero errors. The campaign's SLOW timings are load findings.

Round 3 follow-up: the non-SLOW findings in this campaign repeat the tag and DAV mismatches already tracked here. The run used `ADVERSARIAL_API_ONLY=1` on `job/tasks-mode` at `f620390c724ee08540d38b0ba69c3d12225fc1e4` on 2026-10-01, against a fresh local server. - Valid tag rename `travel` → `journey` returned 409 (probe expects 200). - Tag reconcile after restoring malformed folder metadata and malformed XMP each returned 409 (probe expects 204). Rebuild after deleting the tag Index rows returned 409 and the source listing was empty. - The well-formed Journal alarm probe returned 204 instead of 201. The subsequent DAV cross-date move and delete returned 412 instead of 204. Issue #557 already records that the Journal probe may be using a stale expectation/ETag; these statuses remain unchanged in the probe. No Task storm request timed out in this run. The single-request Task create p50 was 1.904 s and the storm's SLOW threshold was 47.60 s. The server remained alive; the search storm had zero failures, mkdir created 200 items with zero errors, and the rename race had one success and zero errors. The campaign's SLOW timings are load findings.
Author
Owner

New evidence from the #606 branch, HEAD ae45b03ad, using ADVERSARIAL_API_ONLY=1 ADVERSARIAL_SKIP_WEB_BUILD=1 and the local debug server:

  • Tags rename returned 409. Reconcile after repairing Markdown and XMP each returned 409. After deleting rebuildable tag rows, reconcile returned 409 and the rebuilt tag page was empty.
  • DAV Journal accepted the valid alarm PUT with 204 (probe expects 201). The cross-date move and follow-up delete returned 412 (probe expects 204 and a new ETag).
  • The server stayed alive. Search storm had 0 failures, Files mkdir storm created 200 items with 0 errors, and rename race had 1 success with 0 errors. The #606 Files Markdown resolver probes had no findings.
  • The other reported results were marked SLOW on the shared host. The API-only MCP subprobe did not run because its setup file was missing; I filed that runner defect as #654.

These Tag and DAV results match the existing reports #566 and #650. The #606 changes do not touch those routes, so I left their expectations and implementation unchanged for owner review.

New evidence from the #606 branch, HEAD `ae45b03ad`, using `ADVERSARIAL_API_ONLY=1 ADVERSARIAL_SKIP_WEB_BUILD=1` and the local debug server: - Tags rename returned 409. Reconcile after repairing Markdown and XMP each returned 409. After deleting rebuildable tag rows, reconcile returned 409 and the rebuilt tag page was empty. - DAV Journal accepted the valid alarm PUT with 204 (probe expects 201). The cross-date move and follow-up delete returned 412 (probe expects 204 and a new ETag). - The server stayed alive. Search storm had 0 failures, Files mkdir storm created 200 items with 0 errors, and rename race had 1 success with 0 errors. The #606 Files Markdown resolver probes had no findings. - The other reported results were marked SLOW on the shared host. The API-only MCP subprobe did not run because its setup file was missing; I filed that runner defect as #654. These Tag and DAV results match the existing reports #566 and #650. The #606 changes do not touch those routes, so I left their expectations and implementation unchanged for owner review.
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#568
No description provided.