`041_03_01 Query Second Subscription` and `041_03_02 Query Last Subscription` fail against a spec-conformant broker. ### Root cause - The query keyword `Query Context Source Registration Subscriptions` is sent **without an `Accept` header**, so the response is `application/json`. - For `application/json` the `@context` is returned via the **`Link` response header**. The broker also returns the `prev`/`next` pagination links there. Several `Link` values legitimately fold into one comma-separated header (RFC 8288 §3) — all correct. - `Check Pagination Prev And Next Headers` (`resources/AssertionUtils.resource:499`) compares the **whole** `Link` header against just `[prev, next]`, so the extra `@context` value breaks it: - `041_03_01`: `Lengths are different: 3 != 2` - `041_03_02`: whole-header `Should Be Equal` mismatch (`prev, @context` ≠ `prev`) ### Why the sibling tests pass - `031_02` (QuerySubscriptions) and `037_11` (QueryContextSourceRegistrations) use the same assertion but pass `accept=${CONTENT_TYPE_LD_JSON}` → `@context` goes in the body, the `Link` header is pure pagination. `037_11` documents this in an inline comment. ### Proposed fix - Add `accept=${CONTENT_TYPE_LD_JSON}` to the query call in `041_03`, matching `031_02` / `037_11`. ### Files to consider - `TP/NGSI-LD/ContextSource/RegistrationSubscription/QueryContextSourceRegistrationSubscriptions/041_03.robot` - *(optional hardening)* `resources/AssertionUtils.resource` — `Check Pagination Prev And Next Headers` could filter `Link` values by `rel`, making it robust to a legitimately-present `@context` link regardless of content type. Broker behaviour is correct; this is a test-side fix.