Prerequisites: the publisher/subscriber lab. Outcome: identify a failure from observations and check recovery after one controlled change. Allow: 30 minutes with a working training relay.

​
Establish the baseline

Run both clients with the same topic until the subscriber prints three readings. Record the topic and the sequence numbers. Use this successful run as the baseline for each experiment. Do not combine failures until you can explain each one separately. If the relay is unavailable, complete the local filter check and the supplied permission scenario. Record those as local or written exercises, not as successful live tests.

​
Experiment 1: the topic differs

  1. Stop the subscriber with Ctrl+C.
  2. Restart it with --topic academy/alice/humidity.
  3. Keep the publisher on academy/alice/temperature.
  4. Compare both command lines and the publisher’s output.
  5. Restart the subscriber with the original temperature topic.
The humidity subscriber should not print the temperature readings. After correction, the subscriber should receive new readings. The payload and publisher do not need to change.
The topic filter does not match the published topic. The SDK’s local filter check demonstrates this without a relay: python3 data_lab.py check prints wrong filter: False. Silence alone does not prove a connection failure. The restored delivery after correcting only the topic is evidence for the diagnosis.

​
Experiment 2: the publisher stops

  1. Restore the baseline until the subscriber receives three readings.
  2. Stop the publisher with Ctrl+C.
  3. Keep the subscriber running for five seconds.
  4. Check whether the publisher process still exists and whether new readings arrive.
  5. Restart the publisher with its original topic and credential.
Some in-flight readings can arrive after you stop the process. Eventually, no new readings should arrive from that publisher. The subscriber can remain connected while the application has no new data.
An open subscription does not generate readings. The publisher must continue producing them. The lab resets its sequence counter when its process restarts, so the numbers can start at one again. A production design needs a publisher identity or run identifier when sequence numbers must remain unambiguous across restarts.

​
Experiment 3: an operation is denied

Use a training credential that the administrator intentionally restricts. Do not revoke or modify a production credential for this exercise. The administrator must state which publish or subscribe operation the credential denies.
  1. Restore the successful baseline.
  2. Stop the client whose credential you will replace.
  3. Set the restricted credential through the normal credential mechanism.
  4. Attempt the same operation with the same topic.
  5. Collect the client result and the relay’s authorization result.
  6. Restore the original training credential and check delivery again.
Error text and the timing of rejection depend on the SDK and relay version. Some failures appear asynchronously. A missing message is insufficient evidence of a permission denial.
Consider this fictional evidence:
The denied operation is the strongest evidence. A returned publish call does not override the relay’s authorization decision. Restore the authorized training credential, repeat the same operation, and check receipt. Changing a CIDR mask or topic cannot grant the missing permission.

​
Keep a short evidence record

For a failure you cannot explain, record the unresolved question and the next check. Do not label a guessed cause as a finding.

​
Completion and cleanup

Explain how the evidence distinguishes the three failures despite the shared symptom of missing readings. For each live experiment, record both the failure and the recovery result. Mark any written alternative clearly. Stop both clients with Ctrl+C and remove the credential variables from their shells. The lab does not create a background service or retained state. Return to level 103 or review the worked answers.