You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix: Correct event handler ordering for dynamic printer connections
CRITICAL BUG FIX:
The previous implementation had an ordering issue that prevented Spoolman
deduction from working for dynamically connected printers (via API).
PROBLEM:
- 'connected' handler started polling but didn't create monitors
- 'backend-initialized' handler tried to create monitors BEFORE polling started
- Result: pollingService was null → monitors never created for dynamic connections
EVENT ORDERING ISSUE:
During dynamic connections (API reconnect/discovery):
1. Backend initializes → emits 'backend-initialized'
2. backend-initialized handler runs → pollingService is NULL (polling not started)
3. Handler returns early → NO MONITORS CREATED
4. Connection completes → emits 'connected'
5. connected handler starts polling → but monitors already skipped
SOLUTION:
Consolidated all initialization into the backend-initialized handler:
STEP 1: Start polling (creates pollingService reference)
STEP 2: Get pollingService from context (now available)
STEP 3: Create PrintStateMonitor
STEP 4: Create SpoolmanTracker
This handler now fires for BOTH:
- Startup connections (--last-used, --all-saved)
- Dynamic connections (API reconnect, discovery)
CHANGES:
- Moved polling start INTO backend-initialized handler (before monitor creation)
- Removed redundant startPolling() and initializeMonitors() functions
- Simplified 'connected' handler to just log (no duplicate initialization)
- Single initialization path for all connection types
TESTING:
✅ Startup connections (--last-used) → monitors created via backend-initialized
✅ API connect (/api/printers/connect) → monitors created via backend-initialized
✅ API reconnect (/api/printers/reconnect) → monitors created via backend-initialized
0 commit comments