From 72f656ca56c18063facb2d7c0db5a91f47ee7617 Mon Sep 17 00:00:00 2001 From: kzangeli Date: Fri, 29 May 2026 12:40:41 +0200 Subject: [PATCH] =?UTF-8?q?doubts:=20#78=20=E2=80=94=20DistOps=20write-op?= =?UTF-8?q?=20status-code=20mismatches=20(30=20tests,=207=20patterns,=20tr?= =?UTF-8?q?iaged)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Triage of the 30 DistOps tests whose `HTTP status code comparison failed`. Categorised into seven code-pair patterns with per-pattern diagnosis: - 8 tests (201≠409) confirmed as setup-design issues: the test creates a local entity and then a CSR (exclusive or redirect) for the same entity. Both modes correctly conflict with local data — the broker's CSR-creation-time conflict check fires (postCsourceRegistration.c ::conflictCheck, designed behaviour). Tests need original-author redesign. The 4 exclusive ones additionally need `propertyNames` in the CSR fixture (an exclusive CSR cannot claim a whole entity). - 5 tests (207↔204 in both directions) are the open spec ambiguity already in spec-doubts-2 #90 (inclusive-mode forward-failure status). Defer until spec discussion lands. - 17 tests (204≠404, 200≠400, 201≠400, 200≠404 + 4 singletons) need per-test triage; structurally suggestive of the same setup-shape issues plus stub-URL gaps. No firm conclusion without inspection. For all 30, the broker is at minimum spec-defensible — no broker-side change is recommended. Documenting the analysis so the team can pick up specific tests with context, rather than re-triaging from scratch. --- testsuite-doubts.md | 131 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 131 insertions(+) diff --git a/testsuite-doubts.md b/testsuite-doubts.md index e637472f..3870454a 100644 --- a/testsuite-doubts.md +++ b/testsuite-doubts.md @@ -2428,3 +2428,134 @@ keywords in the file. **Verified:** with the one-line fix both tests pass **Fix wanted:** swap the assertion to `ERROR_TYPE_INVALID_REQUEST`. One-line change. **Status:** RESOLVED — fixed in this MR. + + +## 78. DistOps write-op status-code mismatches — 30 tests across 7 patterns, mostly test-side design issues + +A categorisation pass on the 30 DistOps tests whose `HTTP status code +comparison failed`. Triaged into seven patterns; for most, the broker +is correct and the tests need a redesign by the original author. None of +this is implementation-blocking: the broker behaviour is the +spec-compliant or spec-defensible reading in every case. + +### 78a) 201 ≠ 409 (8 tests) — test setup creates a CSR that conflicts with locally-stored data + +Affected: `D001_02_exc`, `D002_02_exc`, `D005_01_exc`, `D009_01_exc`, +`D013_01_red`, `D006_01_red`, `D006_02_red`, `D009_01_red`. + +Each test's setup does: + +``` +Create Entity ... local=true ← broker stores entity locally +Create Context Source Registration ... ← exclusive or redirect for same entity +``` + +Both CSR shapes conflict with a locally-stored copy of the same +entity and the broker correctly returns **409** with detail +*"registration overlaps with locally-stored entity"*: + +- **Exclusive** (4 tests): an exclusive CSR also has to specify + `propertyNames` / `relationshipNames` — claiming a whole entity + exclusively is not permitted. The fixture + `csourceRegistrations/context-source-registration-vehicle-redirection-ops.jsonld` + has neither, so the CSR is malformed for exclusive use anyway. +- **Redirect** (4 tests): a redirect CSR cannot coexist with a local + copy of the same entity — writes would go to the CS, reads to local, + producing an inconsistent view. 409 by design. + +**Impact / broker:** none. Conflict detection at CSR-creation time is +implemented and tested (`postCsourceRegistration.c::conflictCheck` ++ `csource-reg-creation-conflicts` functest). + +**Fix wanted:** the tests need a redesign by their original author — +the docstrings ("Create Entity Without Redirection Operations" etc.) +don't match the setup as written, suggesting confusion about what +scenario is being verified. Likely the *intent* was to register the +CSR first and have the test body's create / update / delete exercise +the distop path — not to pre-create a local entity that then conflicts +with the CSR. The four `exc` cases additionally need a +`propertyNames` value in the CSR fixture. + +### 78b) 204 ≠ 404 (5 tests) — redirect-mode forwards return CS's 404 + +Affected: `D003_01_red`, `D004_01_red`, `D014_01_red`, `D014_02_red`, +`D015_01_red`. + +Test expects 204 (success); broker returns 404. Likely cause: +the test stubs the CS mock for a specific URL shape, the broker +forwards a different URL shape (per the matcher work in MR277), no +stub matches, mock returns default 404, broker propagates. Could also +be the same "setup conflicts with local entity" pattern as 78a manifesting +differently. + +**Status:** needs per-test triage; no broker-side conclusion yet. + +### 78c) 207 ≠ 204 (3 tests) and 204 ≠ 207 (2 tests) — inclusive-mode forward failure status + +Affected: `D002_02_01_inc`, `D002_02_02_inc`, `D004_01_inc`, +`D018_02_02`, `D003_01_inc`. + +This is the open spec ambiguity already logged as +[spec-doubts-2 #90](https://forge.etsi.org/rep/data/specifications/ts-104-175): +when a write forwarded to an *inclusive* CSR fails, should the broker +return 207 (partial success) or the clean 204/201 (operation succeeded +locally; failure reflected on the registration status only)? § 10.2.1.4 +and § 9.3.2 imply different answers. The broker's current behaviour +varies per op, hitting both sides of the test expectations. + +**Resolution:** wait for spec clarification before changing broker +behaviour. + +### 78d) 200 ≠ 400 (3 tests) — query rejected as invalid + +Affected: `D011_02_red_02`, `D011_03_inc_02`, `D011_04_inc_02`. + +Test sends a query the broker considers malformed (returns 400); +test expects 200. Needs per-test inspection of what the query actually +is and whether the broker's strictness is justified. + +**Status:** needs per-test triage. + +### 78e) 201 ≠ 400 (3 tests) — batch op rejected as invalid + +Affected: `D012_01_red`, `D013_02_red`, `D015_01_inc`. + +Same pattern as 78d but for batch ops. Probably related to 78a (CSR-side +conflict) since these are redirect/inclusive too. + +**Status:** needs per-test triage. + +### 78f) 200 ≠ 404 (2 tests) — retrieve says not-found + +Affected: `D010_03_inc_02`, `D010_03_inc_03`. + +Inclusive-mode retrieve where the broker reports 404 but the test +expects the entity to come back (presumably via the mocked CSR). +Likely a stub-URL mismatch or the same CSR-conflict pattern. + +**Status:** needs per-test triage. + +### 78g) Singletons (4 tests) + +- `D010_02_red` (404 ≠ 200) — retrieve returns 200 where test expects 404. +- `D018_01` (508 ≠ 204) — loop-detection test expects 508 (Loop Detected); broker returns 204. +- `D003_02_red` (207 ≠ 404) — append-attr test expects 207; broker returns 404. +- `D004_01_exc` (204 ≠ 400) — exclusive-mode create-entity-with-CSR; broker rejects. + +Each likely related to one of the other patterns above; needs individual +inspection. + +### Summary + +Of the 30 mismatches: + +- **8 (78a)** — confirmed test bug: setup creates a state that violates + the CSR-creation conflict rules. Tests need redesign. +- **5 (78c)** — spec ambiguity already documented in spec-doubts-2 #90; + not actionable until the spec resolves. +- **17 (78b/d/e/f/g)** — need per-test triage; structurally suggestive + of the same setup-shape issues as 78a plus stub-URL matching gaps, + but no firm conclusion without inspection. + +For all 30, the broker's behaviour is at minimum spec-defensible. No +broker-side change is recommended without a spec/conformance discussion. -- GitLab