Commit 86449a7a authored by kzangeli's avatar kzangeli
Browse files

fix: D018_01/03 stub the forwarded create reply like sibling D018_02 

D018_01 (loop detection) and D018_03 (Via-header forwarding) register an
inclusive CSR and POST an entity, but never stub a reply for the forwarded
create. On a broker that reports an unanswered inclusive forward as a partial
success, the create then returns 207 and the test fails at setup, never
reaching its loop-detection (508) / Via-header assertion. Sibling D018_02
already stubs the reply and passes.

Add the matching `Set Stub Reply POST <path> 201` before Create Entity:
/ngsi-ld/v1/entities for D018_01 (default endpoint), /broker1/ngsi-ld/v1/entities
for D018_03 (endpoint=/broker1). With the stub the create + 201 check pass and
the tests proceed exactly like D018_02.

Documented as testsuite-doubts #74. Whether a failed inclusive-write forward
should yield 207 at all is a separate spec ambiguity (spec-doubts-2 #90).
parent 26edb243

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

+5 −0
Original line number Diff line number Diff line
@@ -22,6 +22,11 @@ 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

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

    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}

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

+5 −0
Original line number Diff line number Diff line
@@ -22,6 +22,11 @@ D018_03 Check Via Header Forwarding To Context Source 
    [Documentation]    Verify that the request contains the Via header from both the Context Broker and the Context Source

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



    # The inclusive registration (endpoint=/broker1) 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). The DELETE forward below is

    # already stubbed; the POST one was missing.

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

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

    Check Response Status Code    201    ${response.status_code}

testsuite-doubts.md

+40 −0
Original line number Diff line number Diff line
@@ -2292,3 +2292,43 @@ Or the geometry param should switch to `LineString` (with 
the existing coordinate shape) — but then the test is no

longer a "Within Polygon" test, so option 1 is the right

fix.



## 74. `D018_01` / `D018_03` — forwarded-create reply not stubbed (sibling `D018_02` stubs it), so the inclusive forward yields 207



**Hit:** `D018_01` (loop detection) and `D018_03` (Via-header

forwarding) fail at setup — `Create Entity` returns **207**, the

test asserts **201** — so they never reach their actual assertion

(loop-detection 508 / Via comparison).



**Where:** both register an **inclusive** CSR pointing at the

HttpCtrl mock and then call `Create Entity`, but neither stubs a

reply for the forwarded create. Their sibling `D018_02` does

(`Set Stub Reply POST /broker1/ngsi-ld/v1/entities 201`) and

passes. `D018_03` even stubs the DELETE forward

(`Set Stub Reply DELETE …/entities/${entity_id} 204`) but not the

POST.



**Why it's wrong:** with an inclusive registration the create is

also forwarded to the registered source. If that forward isn't

answered, a broker that surfaces the unanswered forward as a

partial success returns 207. The test assumes 201 — i.e. it

implicitly assumes the forward is answered — but never arranges

the answer. Whether a *failed* inclusive-write forward should

downgrade the operation to 207 at all is itself a spec ambiguity

(see `spec-doubts-2.md` #90 in the TS 104-175 repo), so the test

must not depend on a broker's choice there; it should stub the

forward like `D018_02`.



**Impact / broker:** the broker returns 201 when the inclusive

forward succeeds (proven by `D018_02`) and 207 when it fails —

defensible either way. The inconsistency is in the test, not the

broker.



**Fix wanted:** add `Set Stub Reply POST <path> 201` before

`Create Entity` in `D018_01` and `D018_03`, mirroring `D018_02` —

path `/ngsi-ld/v1/entities` for `D018_01` (default endpoint) and

`/broker1/ngsi-ld/v1/entities` for `D018_03` (`endpoint=/broker1`).

Verified: with the stub, the create + 201 check pass and the test

proceeds exactly like `D018_02` (it then reaches the actual

loop-detection / Via assertions). Implemented in branch

`fix/d018-stub-forwarded-create`.