A gateway can find printers on its own network and USB ports, but nothing
carried that back to the cloud, so adding one in the web app still meant an
operator reading an IP address and a serial number off a machine by hand.
Two schemas, both gateway -> cloud:
- `DiscoveredPrinter`, a candidate the gateway found but cannot drive,
because it is not in that gateway's fleet file.
- A `discovered_printers` variant on the client message, carrying a whole
batch that replaces what that gateway last reported. A printer that has
gone is reported by its absence, and a gateway seeing nothing sends an
empty list.
A candidate deliberately carries no credential, and cannot: a Bambu access
code is on the printer's screen and a PrusaLink API key is in its web UI, so
no probe learns either. What this buys is the address and the identity, which
are the parts an operator would otherwise have to go and look up.
Two details worth keeping in mind downstream:
`ambiguous_with` exists because PrusaLink serves OctoPrint's API, so a probe
that saw only that API cannot honestly claim PrusaLink. The candidate says
`octoprint` and names the alternative, and the operator settles it.
Every string here was chosen by a device on the customer's network - anything
answering an SSDP query or an HTTP probe names itself - so they are untrusted
display strings. Hence the length caps, and hence `DiscoveredPrinter` being
closed where its sibling variants are open: an unbounded LAN-supplied `name`
should not reach a database column or a React tree.
octoturge
6ad400d44c