Awesome Testing
Request training offer

Markdown document

Raport błędu: traffic log detail zwraca 500

Lekcja 22: Weryfikacja i raportowanie pokrycia API

Historical artifacts may name disposable training credentials and environments. Do not reuse credentials, target course systems, or execute archived prompts without authorization.

Bug: traffic log detail returns 500 for a listed correlation ID

Summary

GET /api/v1/traffic/logs/{correlationId} returns 500 Internal Server Error when called with a fresh correlation ID returned by GET /api/v1/traffic/logs for the same client session.

The documented result for an existing correlation ID is 200 with a TrafficLogEntryDto body.

Environment

  • API: https://awesome.byst.re
  • Observed: 2026-08-29 and independently reconfirmed 2026-08-30
  • Authentication: none required for these public traffic endpoints
  • Session scoping: the same unique X-Client-Session-Id is sent to the request, list, and detail endpoints

Preconditions

Generate a unique client session ID. The examples below use uuidgen; no credentials or pre-existing test data are required.

Steps to reproduce

SESSION_ID="traffic-detail-bug-$(uuidgen | tr '[:upper:]' '[:lower:]')"

curl --include \
  --header "X-Client-Session-Id: $SESSION_ID" \
  https://awesome.byst.re/api/v1/traffic/info

curl --silent \
  --header "X-Client-Session-Id: $SESSION_ID" \
  'https://awesome.byst.re/api/v1/traffic/logs?pathContains=%2Fapi%2Fv1%2Ftraffic%2Finfo&page=0&size=20'

From the list response, select the entry whose:

  • clientSessionId equals $SESSION_ID, and
  • path equals /api/v1/traffic/info.

Copy its correlationId, then call:

curl --include \
  --header "X-Client-Session-Id: $SESSION_ID" \
  "https://awesome.byst.re/api/v1/traffic/logs/$CORRELATION_ID"

Expected result

  • Status: 200 OK
  • Body: the TrafficLogEntryDto corresponding to the entry returned by the list endpoint
  • The response correlation ID matches $CORRELATION_ID

Actual result

  • Status: 500 Internal Server Error
  • Content-Type: application/json;charset=UTF-8
  • Body:
{"message":"Internal server error"}

Reproduction evidence

An independent reproduction on 2026-08-29 produced:

  • client session ID: codex-review-b5fd6bf2-1fcd-46a3-9ed5-2dd86785848a
  • GET /api/v1/traffic/info: 200
  • listed correlation ID: 1fbcb8c0-77a6-439c-aeb5-0229ee4109cd
  • detail request with the same session header: 500
  • detail response: {"message":"Internal server error"}

The original exploratory agent reproduced the same behavior more than once. A random unknown correlation ID returns the expected empty 404, so routing and the missing-record path remain functional.

A fresh backend-report verification on 2026-08-30 produced:

  • client session ID: codex-backend-report-f2761f9c-faeb-41ae-a104-a69af9cf691b
  • GET /api/v1/traffic/info: 200
  • GET /api/v1/traffic/logs: 200
  • listed correlation ID: 801a1c92-6fd4-42c6-804c-9f38f97aa720
  • detail request with the same session header: 500
  • detail content type: application/json;charset=UTF-8
  • detail response: { "message": "Internal server error" }

Impact

  • Consumers cannot retrieve the detail representation of a traffic entry they just obtained from the list endpoint.
  • The documented 200 path cannot be covered by a reliable API regression test.
  • Any UI or diagnostic workflow that opens an individual traffic record is likely to fail for existing records.

Contract comparison

api-docs.json documents:

  • 200 for an existing traffic log, with a TrafficLogEntryDto body
  • 404 when the traffic log does not exist

The live 500 for an existing, session-matching record contradicts this contract.

Suggested investigation

  1. Find the server exception for the detail request at the reproduction timestamp.
  2. Compare the deployed backend revision and traffic configuration with the local test-secure-backend checkout; its controller integration test expects the same list-to-detail flow to return 200.
  3. Inspect the direct lookup paths in TrafficLogService and TrafficLogRepository, especially DTO conversion and hydration of stored request/response header and body fields.
  4. Compare one record that fails through the detail endpoint with its successful representation in the list response.
  5. Add a backend regression test that creates a session-scoped traffic record, obtains its correlation ID from the list endpoint, and retrieves it through the detail endpoint using the same X-Client-Session-Id.

Do not change the Playwright suite to expect 500; keep the successful detail path blocked until the backend behavior is corrected and verified live.