GRAYLOG - Chapter 10, Exercise 1 Solution
==========================================================
Why Step 5 Switches from requestId to correlationId

PROBLEM
-------
Explain, in your own words, why Step 5 switches from requestId to
correlationId - what specifically changed about the nature of what's
being traced?

SOLUTION
--------
Step 4 was tracing ONE specific HTTP request - the request that
produced the original error line found in Step 2. Per Chapter 4's own
real definition, requestId is exactly the right field for that: it
correlates the log lines produced while handling a single request.

Step 5 discovered that request's own downstream failure looked Flux-
shaped rather than search-shaped - meaning the actual underlying problem
wasn't confined to one HTTP request at all, but was part of a broader,
cross-service job (a Flux sync run touching the RMS integration
cluster). Per Chapter 4's own real scope distinction, correlationId -
not requestId - is the field that ties together log lines from a whole
cross-service job, potentially spanning multiple individual requests.

ANSWER: The switch happens because what's being traced changed scope -
from one single HTTP request (requestId's own real job) to a broader
cross-service Flux job that request turned out to be just one small
part of (correlationId's own real job). The investigation genuinely
outgrew the narrower field once its true scope became clear.

----
WHY THIS WORKS AS AN ANSWER

This directly applies Chapter 4's own requestId/correlationId scope
distinction, and Chapter 8's own Scenario 2 already modeled the same
kind of switch for a different starting point. Recognizing when an
investigation has outgrown a request-scoped field and needs a job-scoped
one instead is exactly the judgment call this capstone was built to
exercise.