viewit/KX-Bridge-Release
10
16
Fork 9
Code Issues 4 Pull Requests Actions Packages Projects Releases 54 Wiki Activity

Spoolman slot mapping doesn't survive a restart (and multi-printer setups overwrite each other) #80

New Issue
Closed
opened 2026-07-02 07:05:05 +02:00 by walterioo · 2 comments
walterioo commented 2026-07-02 07:05:05 +02:00
Contributor
Copy Link

Description

The AMS-slot in Spoolman spool mapping doesn't stick. You set it, it works fine for that session, but after a restart it's gone. On a two-printer bridge it's worse: mapping one printer wipes out the other's. Digging in, there are two separate bugs.

Bug 1 - the mapping never actually gets saved or loaded (swallowed NameError).
Both the load (in __init__) and the save (in handle_kx_spoolman_set_active) call config_loader._find_config_file() — but the module is imported as env_loader up top (kobrax_moonraker_bridge.py:32), so config_loader doesn't exist in that scope. It throws NameError, and the bare except around it just swallows it. So nothing ever gets read back on startup or written on change; the mapping only lives in memory for the current session.

Bug 2 - the map is global, so multi-printer setups overwrite each other.
Even with Bug 1 fixed, the mapping is kept in a single global [spoolman] slot_spools key that every printer instance shares, so two AMS units end up stepping on each other. Same shape as the filament-profile problem from #74/#75.

Steps to Reproduce

  1. Set [spoolman] server=... and map a few AMS slots to spools from the UI.
  2. Restart the bridge.
  3. Hit GET /kx/spoolman/status ->slot_spools comes back empty.
  4. With two printers: map printer 1, then map printer 2, and printer 1's mapping is gone.

Expected Behavior

The mapping sticks across restarts, and each printer keeps its own.

Actual Behavior

It's dropped on every restart, and with two printers they clobber each other because they share one global key.

Environment

  • KX-Bridge Version: nightly (a16062f)
  • OrcaSlicer Version: 2.4.1-KX1
  • Moonraker/Klipper Version: bridge-emulated (v0.9.3-1)
  • Operating System: Ubuntu 24.04 (Docker)
  • Installation: Docker

Logs

Nothing shows up in the logs — which is half the problem. The NameError gets
swallowed, so persistence just quietly no-ops. (The fix logs it via log.warning
so a real failure would actually surface.)
## Description The AMS-slot in Spoolman spool mapping doesn't stick. You set it, it works fine for that session, but after a restart it's gone. On a two-printer bridge it's worse: mapping one printer wipes out the other's. Digging in, there are two separate bugs. **Bug 1 - the mapping never actually gets saved or loaded (swallowed `NameError`).** Both the load (in `__init__`) and the save (in `handle_kx_spoolman_set_active`) call `config_loader._find_config_file()` — but the module is imported as `env_loader` up top (`kobrax_moonraker_bridge.py:32`), so `config_loader` doesn't exist in that scope. It throws `NameError`, and the bare `except` around it just swallows it. So nothing ever gets read back on startup or written on change; the mapping only lives in memory for the current session. **Bug 2 - the map is global, so multi-printer setups overwrite each other.** Even with Bug 1 fixed, the mapping is kept in a single global `[spoolman] slot_spools` key that every printer instance shares, so two AMS units end up stepping on each other. Same shape as the filament-profile problem from #74/#75. ## Steps to Reproduce 1. Set `[spoolman] server=...` and map a few AMS slots to spools from the UI. 2. Restart the bridge. 3. Hit `GET /kx/spoolman/status` ->`slot_spools` comes back empty. 4. With two printers: map printer 1, then map printer 2, and printer 1's mapping is gone. ## Expected Behavior The mapping sticks across restarts, and each printer keeps its own. ## Actual Behavior It's dropped on every restart, and with two printers they clobber each other because they share one global key. ## Environment - KX-Bridge Version: nightly (`a16062f`) - OrcaSlicer Version: 2.4.1-KX1 - Moonraker/Klipper Version: bridge-emulated (v0.9.3-1) - Operating System: Ubuntu 24.04 (Docker) - Installation: Docker ## Logs ``` Nothing shows up in the logs — which is half the problem. The NameError gets swallowed, so persistence just quietly no-ops. (The fix logs it via log.warning so a real failure would actually surface.) ```
walterioo commented 2026-07-02 07:27:53 +02:00
Author
Contributor
Copy Link

Testing fixes ATM, waiting on a print to finish to validate persistance.
Will PR upon succesful test.

Testing fixes ATM, waiting on a print to finish to validate persistance. Will PR upon succesful test.
viewit commented 2026-07-02 21:31:43 +02:00
Owner
Copy Link

Both bugs confirmed and fixed in PR #83 by @walterioo — merged. Thank you for the thorough analysis and the ready-to-merge fix!

Fix will be live with the next nightly build.

Both bugs confirmed and fixed in PR #83 by @walterioo — merged. Thank you for the thorough analysis and the ready-to-merge fix! Fix will be live with the next nightly build.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Something is not working
bug
documentation
duplicate
This issue or pull request already exists
enhancement
New feature
enhancement
help wanted
Need some help
invalid
Something is wrong
known-issue
question
More information is needed
wontfix
This won't be fixed
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
viewit
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: viewit/KX-Bridge-Release#80
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?