Files
bambuddy/backend
maziggy 25c36ba5de fix(library): stop reporting success for a bulk add that queued nothing (issue #3112)
POST /library/files/add-to-queue reported every per-file rejection in an
    errors array and returned 200 regardless. A caller that checks the status
    code saw a successful request, no visible failure, and no queue item.
    That is a 400 now when nothing at all was added, with the same reasons in
    the body. A call that created some items still succeeds, because it did.

    The items it created were aimed at nothing. The route always wrote
    printer_id=None with no target_model, and the scheduler dispatches on one
    or the other -- so those rows matched neither branch and could never be
    picked up by anything. They sat in Unassigned until someone opened each
    one by hand.

    The request takes an optional printer_id or target_model for the batch,
    and with neither it aims each file at the model its own G-code declares.
    Only when a printer of that model is active: owning no H2D is the user's
    situation rather than their mistake, so the file still queues as the
    unassigned row it has always been, rather than gaining a target nothing
    can answer.

    Three gates POST /queue/ has applied for a while now apply here too,
    because an item reaching the scheduler through this route has to be as
    printable as one reaching it through that one: the cross-model check that
    stops a file sliced for one printer being dispatched to another (#2578),
    the filename check that would otherwise surface as a failed upload hours
    later (#1540), and the filament requirements the scheduler matches before
    handing a model-based item to hardware.

    Nothing inside Bambuddy calls this endpoint -- the Library's own Print
    action goes through the queue API with a printer already chosen -- which
    is how it came to drift this far from it.

    -----

    fix(library): scope add-to-queue file reads to the caller

    The bulk add resolved its files by raw id. Every other read in this
    module goes through the ownership gate, and so does the single-item
    queue path; this one did not.

    Invisible rows are dropped before the loop, so they report as the plain
    "File not found" an unknown id already gets.
2026-09-20 13:38:54 +02:00
..