Commit a1c606fd authored by kzangeli's avatar kzangeli
Browse files

fix(local): D018_01 loop detection uses a redirect registration so 508 is spec-correct 



D018_01 registered an INCLUSIVE CSR and asserted 508 Loop Detected, but
TS 104-176 § 6.3.18 maps 508 only to the exclusive/redirect single-source
case (inclusive falls under the 207 group; an inclusive loop is served from
the local copy). A spec-conformant broker therefore does not return 508 for
an inclusive registration, so the test failed.

Switch the registration to redirect — the mode § 6.3.18 actually maps to 508
— keeping the test's stated intent ("a loop is detected") and the 508
assertion. Redirect (not exclusive) because the fixture carries entities only,
no property/relationship names, which an exclusive registration requires.

Documented in testsuite-doubts.md #102; the underlying § 9.7 vs § 6.3.18
ambiguity is logged separately (spec-doubts-2 #93) for ETSI TC DATA.

Co-Authored-By: default avatarClaude Opus 4.8 (1M context) <noreply@anthropic.com>
parent 910af4d7

TP/NGSI-LD/DistributedOperations/LoopDetection/D018_01.robot

+9 −4
Original line number Diff line number Diff line
@@ -22,10 +22,15 @@ D018_01 Loop Detection With Via Header 
    [Documentation]    Verify that a loop is detected when the Via header contains the broker's identifier.

    [Tags]    since_v1.8.1    dist-ops    4_3_3    cf_06    5_6_6    6_3_18



    # The inclusive registration forwards the create to the mock; that forward

    # The redirect registration forwards the create to the mock; that forward

    # must be answered so the operation returns 201 (cf. sibling D018_02, which

    # stubs the same reply). Without it a broker that surfaces the unanswered

    # forward as a partial success returns 207 and the test fails at setup.

    # stubs the same reply). 508 Loop Detected is defined (TS 104-176 § 6.3.18)

    # only for an exclusive/redirect single-source registration that resolves

    # back onto the broker — for an inclusive registration the data is held

    # locally and a loop merely suppresses the forward, so the registration

    # used here must be exclusive/redirect for the 508 assertion to be

    # spec-correct. Redirect is used because this fixture carries entities only

    # (no property/relationship names), which an exclusive registration requires.

    Set Stub Reply    POST    /ngsi-ld/v1/entities    201

    ${response}=    Create Entity    ${entity_payload_filename}    ${entity_id}

    Check Response Status Code    201    ${response.status_code}
@@ -49,7 +54,7 @@ Create Entity And Registration On The Context Broker And Start Context Source Mo 
    ...    ${registration_id}

    ...    ${registration_payload_file_path}

    ...    entity_id=${entity_id}

    ...    mode=inclusive

    ...    mode=redirect

    ${response}=    Create Context Source Registration With Return    ${registration_payload}

    Check Response Status Code    201    ${response.status_code}

testsuite-doubts.md

+36 −0
Original line number Diff line number Diff line
@@ -2709,3 +2709,39 @@ redirect CSR stripped the fragment and the second-and-onwards got NO 
forward (D008_01_red-class); and batch update 404-gated on local

existence BEFORE dispatch, where § 9.4 reserves ResourceNotFound for

"unknown locally AND no matching registrations". Both fixed broker-side.)**







## 102. `D018_01` — loop-detection 508 asserted against an *inclusive* registration



**Status:** RESOLVED locally — registration switched from inclusive to

redirect.



**Hit:** `D018_01 Loop Detection With Via Header` registers an

**inclusive** CSR (`mode=inclusive`, fixture

`context-source-registration-vehicle-redirection-ops.jsonld`), provokes a

loop by replaying the broker's own `Via` alias on a DELETE, and asserts

**508 Loop Detected**.



**Why it's wrong:** TS 104-176 § 6.3.18 enumerates **508 Loop Detected**

**only** for an *exclusive/redirect* single-source registration that

"is registered to redirect back onto the Context Broker". For an

**inclusive** registration the data is also held locally, so a loop simply

suppresses the (looping) forward and the operation is served from the local

copy — DELETE → 204, not 508. No clause maps an inclusive loop to 508.

A spec-conformant broker therefore does not return 508 here, and the test

fails. (Spec ambiguity logged in TS 104-175 spec-doubts-2.md #93; to be

raised with ETSI TC DATA.)



**Impact / broker:** none — the broker returns 508 for an exclusive/redirect

single-source loop on a write, and serves locally (204) for an inclusive

loop, both per § 6.3.18 / § 9.7.



**Fix wanted:** register a **redirect** (or exclusive) CSR — the mode

§ 6.3.18 actually maps to 508 — and keep the 508 assertion. Redirect is the

natural choice here: the existing fixture carries entities only (no

property/relationship names), which an *exclusive* registration requires

but a redirect one does not. **Verified:** with `mode=redirect` the create

forwards + 201-checks, the replayed-Via DELETE returns 508, and the test

asserts exactly its stated intent ("a loop is detected"). Implemented in

`integration/all-fixes`.