Capture `x-request-id` from HTTP responses and attach to Report Portal test entries

[silvi-t]

Summary

When a test fails, debugging requires correlating the test with the actual HTTP request traces in the Jaeger UI. Currently, x-request-id headers (assigned by the gateway/Envoy on every response) are only used in the dedicated tracing tests. There's no mechanism to surface these IDs in Report Portal, making it difficult to find the relevant Jaeger traces for a failed test.

Problem

After a test failure in CI, an engineer needs to:

1. Open Report Portal to see which test failed
2. Manually try to reproduce or guess what happened at the gateway level
3. Search Jaeger blindly without knowing which request IDs belong to the failed test

There is no link between the test result in Report Portal and the distributed traces in Jaeger.

Proposed Solution

Capture the trace request ID header from every HTTP response made by KuadrantClient during a test and attach the collected IDs to the corresponding test entry in Report Portal.

Configurable header name

The header carrying the request ID depends on how tracing is configured in the Kuadrant CR. Currently the default is x-request-id (set by Envoy/Istio), but users can configure a different header name on the Kuadrant CR when setting up tracing. The testsuite must support this:

• Add a new setting in config/settings.yaml with the default value of x-request-id under tracing.request_id_header.
• Users can override it in config/settings.local.yaml or via KUADRANT_TRACING__request_id_header env var to match whatever header their Kuadrant CR is configured to use.
• KuadrantClient reads this setting to know which response header to capture.

Implementation approach

1. Collect request IDs in KuadrantClient (testsuite/httpx/__init__.py):

   • After each request, extract the configured request ID header from the response and store it in a list on the client instance (similar to the existing denied_request_ids tracking pattern).

2. Expose collected IDs via the client fixture (testsuite/tests/singlecluster/conftest.py):

   • The client fixture already yields a KuadrantClient instance — the collected request IDs are accessible after the test runs.

3. Write IDs to JUnit XML as Report Portal properties (testsuite/tests/conftest.py):

   • Add a pytest hook (or extend the existing pytest_runtest_makereport) that, on test failure (or optionally on every test), appends the collected request IDs as __rp_request_ids user property.
   • The existing RP integration pipeline (testsuite-rptool) already imports __rp_-prefixed properties from JUnit XML.

4. Report Portal display:

   • Request IDs appear as test attributes/properties in Report Portal.
   • Engineers can copy any ID and search for it in Jaeger UI using the request_id tag (e.g., tags={"request_id": "<id>"}) to see the full distributed trace across kuadrant-filter, Authorino, Limitador, and the gateway.

Optional enhancements

• Jaeger deep-link: If the Jaeger/Tempo URL is known from config, generate a clickable link directly to the trace search (e.g., http://<jaeger>/search?service=kuadrant-filter&tags={"request_id":"<id>"}).
• Scope control: Only attach request IDs on failure to keep Report Portal entries clean for passing tests.
• Multiple clients: Handle tests that use more than one client instance (e.g., client and client2).

Existing patterns to leverage

• KuadrantClient already tracks X-Testsuite-Tracking UUIDs and denied_request_ids — the same pattern can be reused for request ID collection.
• The pytest_runtest_makereport hook in testsuite/tests/conftest.py already writes __rp_rerun_* properties to report.user_properties — request IDs can be added the same way.
• Tracing tests already extract x-request-id via response.headers.get("x-request-id") and use it to query Jaeger — the query pattern is proven.
• Dynaconf settings with KUADRANT_ prefix env var override is already the standard config mechanism in the testsuite.

Acceptance criteria

• The request ID header name is configurable via tracing.request_id_header setting (default: x-request-id)
• Request ID headers are captured from all HTTP responses made by KuadrantClient during test execution
• Captured request IDs are attached to the test entry in Report Portal (via __rp_ user properties in JUnit XML)
• On test failure, an engineer can take a request ID from Report Portal and find the corresponding trace in Jaeger
• No performance impact on test execution (header extraction is lightweight)
• Works with the existing testsuite-rptool import pipeline without modifications