Refactor MQTT course and bound backend message processing

Move lesson source into the teaching structure, align the course path with the learner's Go and DevOps experience, and add the interactive lesson guides. Add advanced DevOps lifecycle study as a separate section.

Bound MQTT message work and drain accepted jobs during shutdown; align the backend implementation with the revised course through Section 6.
This commit is contained in:
2026-10-22 10:19:56 +03:30
parent f9ab91ed60
commit fb30e8e884
70 changed files with 7492 additions and 312 deletions
@@ -0,0 +1,45 @@
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>HTTP and MQTT Evidence — Quick Reference</title>
<link rel="stylesheet" href="../assets/lesson.css">
</head>
<body>
<main class="page">
<p class="eyebrow">Robot Market · Quick reference</p>
<h1>Three acknowledgements, three meanings</h1>
<p class="dek">When a backend tells a caller that a device command is progressing, name the component that produced each piece of evidence.</p>
<section class="card">
<h2>Evidence map</h2>
<table>
<thead><tr><th>Evidence</th><th>Who produced it?</th><th>What it supports</th><th>What it does not prove</th></tr></thead>
<tbody>
<tr><th>HTTP 202</th><td>Go HTTP server</td><td>The request was accepted for processing.</td><td>Broker publication or device execution.</td></tr>
<tr><th>QoS 1 PUBACK</th><td>MQTT receiver on this hop</td><td>The corresponding QoS 1 PUBLISH exchange was acknowledged, subject to the reason code.</td><td>That a device accepted or completed the business action.</td></tr>
<tr><th>Command result</th><td>Device application, delivered back through MQTT</td><td>The result contract reports accepted, completed, or rejected work.</td><td>That the report is authentic without identity and authorization checks.</td></tr>
</tbody>
</table>
</section>
<div class="flow" aria-label="Evidence sequence">
<div class="step">API admission<br><strong>HTTP 202</strong></div><span class="arrow">→</span>
<div class="step">Broker hop<br><strong>PUBACK</strong></div><span class="arrow">→</span>
<div class="step">Device application<br><strong>Command result</strong></div>
</div>
<section class="card callout">
<h2>Use this sentence</h2>
<p>“The API accepted command <code>C</code>. The broker acknowledged the publish. The device result is still pending.”</p>
<p class="small">If the API process keeps command state only in memory, an HTTP 202 is not a promise that the record survives a process restart.</p>
</section>
<footer>
<p><a href="../lessons/0008-http-acceptance-vs-completion.html">Open Lesson 8</a> · <a href="../course-source/07-command-response.md">Section 7 source lesson</a></p>
<p>Primary sources: <a href="https://datatracker.ietf.org/doc/rfc9110/">RFC 9110 §15.3.3</a> and the <a href="https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html#_Toc3901120">OASIS MQTT 5.0 specification</a>.</p>
</footer>
</main>
</body>
</html>
@@ -0,0 +1,18 @@
<!doctype html>
<html lang="en">
<head><meta charset="utf-8"><meta name="viewport" content="width=device-width, initial-scale=1"><title>Message Processing Lifecycle — Quick Reference</title><link rel="stylesheet" href="../assets/lesson.css"></head>
<body><main class="page">
<p class="eyebrow">Robot Market · Quick reference · Lessons 5–7</p><h1>From bytes to a matched command result</h1>
<p class="dek">Use this map to locate the boundary where a failure happened. An event in one row does not automatically prove the next row.</p>
<section class="card"><table><thead><tr><th>Stage</th><th>Code owner</th><th>Success means</th><th>Still does not prove</th></tr></thead><tbody>
<tr><th>Route + contract</th><td><code>topic.go</code> builders/parser, <code>Decode</code></td><td>Publish names and filters are distinguished; topic shape and typed payload passed validation.</td><td>Who published; Mosquitto ACL owns that access decision.</td></tr>
<tr><th>Application state</th><td>Service + store</td><td>A use case updated the in-memory view or recorded an outcome.</td><td>That the record survives a process restart.</td></tr>
<tr><th>Queue admission</th><td>Bounded dispatcher</td><td>Work entered a finite RAM queue or returned Full/Stopping.</td><td>That a worker completed or that MQTT will redeliver.</td></tr>
<tr><th>Command publish</th><td>AutoPaho adapter</td><td>PUBACK acknowledged the QoS 1 publication hop.</td><td>That the device received, accepted, or completed the business action.</td></tr>
<tr><th>Device result</th><td>Response handler + command store</td><td>Validated device/application evidence matched identity and correlation.</td><td>Authenticity without broker and application authorization.</td></tr>
<tr><th>HTTP status</th><td>HTTP handler</td><td>The API represented its current known command state.</td><td>That an asynchronous device operation is already complete.</td></tr>
</tbody></table></section>
<div class="flow" aria-label="message and command flow"><div class="step">Parse + validate</div><span class="arrow">→</span><div class="step">Apply use case</div><span class="arrow">→</span><div class="step">Admit bounded work</div><span class="arrow">→</span><div class="step">Publish + correlate</div><span class="arrow">→</span><div class="step">Report evidence</div></div>
<section class="card callout"><h2>Fast incident questions</h2><ol><li>Which process produced this evidence?</li><li>What state changed, and where does it live?</li><li>Could the earlier stage have acknowledged before this stage finished?</li><li>What does restart, timeout, or queue saturation erase or leave unknown?</li></ol></section>
<footer><p>Lessons: <a href="../lessons/0005-contract-validation.html">5</a> · <a href="../lessons/0005a-backend-message-processing.html">5A</a> · <a href="../lessons/0006-bounded-message-work.html">6</a> · <a href="../lessons/0007-command-state.html">7</a> · <a href="../lessons/0008-http-acceptance-vs-completion.html">8</a></p><p>Return to <a href="../README.md">teaching workspace home</a>.</p></footer>
</main></body></html>