Attempt the level 103 capstone first. The reported symptom is a connected subscriber that receives no objects.

​
1. Choose the first check

Check what “connects fine” means in the client’s logs. An allocated client handle, a transport connection, and an accepted subscription are different events. Record the endpoint, identity, topic or track, and last successful operation. This establishes which later checks are relevant. Then check authorization for the requested operation. A credential prefix can suggest its intended use, but server policy determines the actual permission.

​
2. Identify two possible causes

The publisher might have stopped producing objects while the subscriber remained connected. Check activity at the publish call and delivery through the relay. Alternatively, the subscriber might request a different namespace, track, or application topic. Compare the exact values on both sides. An open connection cannot correct a name mismatch. These hypotheses produce similar symptoms but require different corrections. The debugging lab makes the distinction observable.

​
3. Select useful observations

Use tenant logs for the affected identity and operation where available. Use traffic accounting to compare publisher and subscriber activity. Use transport metrics when the evidence points to connection behavior. The deployed observability features determine which fields are available; do not invent a dashboard result.

​
Completion criteria

Your answer passes when it distinguishes the hypotheses and specifies the evidence needed to choose between them. It must also state how you would check recovery after the correction. For the lab, receipt of three new numbered readings is a concrete recovery check. Finish the publisher/subscriber lab and its failure experiments before claiming live SDK experience. A written diagnosis demonstrates reasoning; a live result demonstrates the exercised system behavior.