doubts: #78 — DistOps write-op status-code mismatches (30 tests, 7 patterns, triaged)

**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.