octoturgeandClaude Opus 5 48672b1f45 Execute start_print, and never await it on the uplink task
The gateway can now run a cloud-dispatched print: download the job file from
the presigned URL in the command, then hand it to the existing
`upload_project_file`, which derives the filament mapping from the archive,
transfers it over FTPS and starts it.

## The download refuses to be a weapon

`src/uplink/download.rs` checks the HTTP status before reading a byte,
because an expired presigned URL answers 403 with an XML error document and
writing *that* to a printer as a project is the worst outcome available. It
rejects a `Content-Length` over 256 MiB before reading, and enforces the cap
while streaming as well, so a server that lies or omits the length cannot
make a small gateway box buffer until the OOM killer arrives. A byte count
that disagrees with `Content-Length` is an error: a `.3mf` is a zip, and a
truncated one loses the central directory the printer needs. HTTPS only, no
redirects, and the URL is stripped from error messages.

`PrinterCommand` no longer derives `Debug` for the same reason - `dispatch`
logs every command, and a presigned URL is a bearer credential until it
expires. It prints as `<redacted>`.

## Why it is spawned

`start_print` is the one command that cannot be answered inline, and the
reason is not latency. Everything else here is an MQTT publish returning in
milliseconds. This downloads tens of megabytes and then transfers them at a
measured 0.2 MiB/s - about four minutes for a 50 MB project - and awaiting
that inside the uplink's `select!` loop stops heartbeats and, far worse,
stops telemetry for the duration.

No telemetry is what makes spawning mandatory rather than tidy. The cloud now
derives a job's state from the telemetry that follows a start, so a gateway
that goes silent for four minutes during every job start withholds exactly
the information the job depends on - while the backend times the command out
after ten seconds and concludes the start failed. The job would be requeued
onto a printer that was busy printing it.

So the `ok` means "accepted, working on it", which is all a start reply was
ever trusted to mean. `runs_for_minutes` is an exhaustive match rather than a
`matches!`, so a new variant has to make that choice instead of defaulting to
the stall.

The gap this leaves is honest and recorded in the code: a failure after the
ack has no `CommandResult` to travel on, because answering later needs an
outbound channel this loop does not have. Until it does, the gateway's log is
where the reason lives and the backend reaps the job.

reqwest 0.12 with `rustls-tls-native-roots`, not 0.13: 0.13 pulls
`webpki-root-certs` under CDLA-Permissive-2.0, which is not on the allow
list, and `aws-lc` brings OpenSSL-licensed C. `cargo deny check licenses`
passes. 54 tests.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-10-15 22:53:47 +00:00

continuum-proxy

Edge gateway daemon for the Continuum print farm platform. Runs on a Linux SBC on-site, talks to printers over the LAN, and keeps a connection to the cloud control plane (continuum-backend).

What's real right now

  • Bambu MQTT - a real client for both protocol generations (MQTT v3.1.1+BambuMQTT v1 on older firmware, MQTT v5+BambuMQTT v2 on current firmware), auto-detected per printer on connect (a firmware update can move the same physical printer between them, so this isn't something config can hard-code once and forget - see printer/bambu.rs's BambuProtocolPreference::Auto). Request/reply correlation via sequence_id, an in-memory print.push_status cache that merges v1's partial updates and replaces on v2's full ones, and TLS trust that auto-pins a printer's certificate via trust-on-first-connect the first time the bundled CA doesn't verify (printer/bambu.rs's ensure_trusted) - see printer/bambu_mqtt.rs's doc comment for the full protocol write-up.
  • Marlin/RepRap serial - a real held-open serial connection that paces gcode lines by Marlin's own "ok" acknowledgment (printer/marlin_serial.rs).
  • Wire shapes from schemas, not hand duplication - Bambu's raw MQTT JSON is built straight from continuum-schemas' JSON Schema files via continuum-schema-instance, instead of a second hand-written copy of every request shape drifting out of sync with the schema.
  • Cloud uplink - a WebSocket client to continuum-backend that connects, sends a heartbeat on a timer, and reconnects on drop (src/uplink/).
  • go2rtc watchdog - restarts the camera-restreaming subprocess if it dies (src/go2rtc.rs).
  • Bambu file upload - implicit FTPS (port 990) into the printer's own cache/ directory (src/printer/bambu_ftps.rs, via BambuPrinter::upload_file). Confirmed live against a P1P on 2026-10-03: login, binary mode, and the transfer all work, byte count matched exactly.
  • Print status - print.push_status parsed into PrintReport with real job progress, temperatures, fans and HMS entries. Confirmed live on both generations (idle P1P on v1, H2C 20% into a job on v2); regression fixtures from those captures are in tests/fixtures/.

Examples worth knowing

  • cargo run --example live_reports [printer-id] - read-only, safe against a printer that is mid-print. Connects, reports firmware, and watches the status stream. Redirect stderr to capture raw payloads.
  • cargo run --example bambu_idle_checks -- <printer-id> - writes (FTPS upload, fan speed). Requires an explicit printer id and refuses to run unless that printer reports gcode_state: "IDLE".

What routes between the cloud and the printers

The uplink and the printer fleet are wired together, in both directions (uplink/mod.rs):

  • Up: every 5s, one PrinterTelemetry snapshot per printer that has reported, batched into a single Telemetry message. Verified live against a P1P and an H2C.
  • Down: a Command from the cloud is looked up by our own printer id, executed, and answered with a CommandResult. The set of commands is deliberately small - a fan speed and a single gcode line - and deliberately has no "start a print" variant; see PrinterCommand.

One quirk worth knowing: a Bambu on protocol v1 only sends a complete status when asked, so each telemetry tick also fires a pushing.pushall for the next one. A v1 printer's telemetry is therefore one tick behind, which is why it shows up on the second frame rather than the first.

What's still a stub

start_uploaded_file - the MQTT command that actually starts a print from an uploaded file - is written but has deliberately never been fired, since that commits a machine to hours of work. Its doc comment lists the three details to confirm on the first real attempt. upload_file is proven, but only with a small text file, not a multi-megabyte sliced .3mf.

PrusaLink (REST) and Klipper/Moonraker (WebSocket) - printer/prusa.rs and printer/klipper.rs just println! what they'd send. Also not built yet: local buffering for telemetry across connectivity gaps (so telemetry produced while the uplink is down is simply lost), LAN printer discovery (SSDP/mDNS), and the mechanical plate-changer interface.

Getting started

cp .env.example .env
cargo run                                  # the daemon: connects every configured printer, then runs the cloud uplink + go2rtc watchdog

cp printers.example.toml printers.toml     # fill in your real printers (gitignored)
cargo run --example auto_connect_bambu     # checks/auto-pins each Bambu printer's certificate, no MQTT needed
cargo run --example test_bambu_certs       # narrower: just the raw TLS handshake, no auto-pinning
cargo run --example printer_polymorphism   # standalone trait+enum demo, fake data, no network/env needed
cargo run --example bambu_commands_demo    # round-trips hand-written structs against real captured Bambu JSON

Structure

src/
  main.rs               Loads+connects the printer fleet, then runs the uplink and go2rtc watchdog side by side
  config.rs             Loads settings from environment variables
  fleet.rs              Loads printers.toml into ready-to-use PrinterHandles
  uplink/                WebSocket client to continuum-backend: connect, heartbeat, reconnect on drop
  go2rtc.rs             Restarts the go2rtc camera-restreaming process if it dies
  printer/
    mod.rs               GenericPrinter trait + PrinterBase + PrinterHandle enum - the trait+enum
                         "inheritance" pattern this project uses instead of class inheritance
    bambu.rs             The real Bambu printer type: cert trust, protocol version auto-detect, commands
    bambu_mqtt.rs        The real MQTT wiring underneath bambu.rs - see its doc comment for the protocol details
    bambu_commands/      Hand-written serde structs mirroring continuum-schemas' bambulab/ shapes
    marlin_serial.rs     A real held-open Marlin/RepRap serial connection
    prusa.rs, klipper.rs Still stubs - see "What's still a stub" above
examples/
  auto_connect_bambu.rs   Checks/auto-pins every Bambu printer's certificate (no MQTT)
  test_bambu_certs.rs     Narrower: just a raw TLS handshake per Bambu printer
  printer_polymorphism.rs Standalone trait+enum demo, five fake printers, no network needed
  bambu_commands_demo.rs  Round-trips bambu_commands' structs against real captured Bambu JSON

printers.toml (gitignored - copy from printers.example.toml) holds real per-printer connection details: host, access code/API key/serial port depending on vendor, and - for Bambu - an optional per-printer CA certificate override (see certs/README.md; most printers don't need one, since connect() auto-pins automatically).

Learning Rust through this repo

src/printer/mod.rs's doc comment is where the "how do I do inheritance without classes" question lives - trait (shared behavior) + struct (shared fields) + enum (the closed set of concrete types), instead of GenericPrinter -> BambuPrinter/PrusaLinkPrinter/... class inheritance. Run printer_polymorphism to see it work end to end without needing any real printer on the network.

S
Description
Continuum platform: continuum-proxy
Readme
914 KiB
Languages
Rust 100%