Reliable Shopify 4×6 PDFs to Windows thermal printer: queue and recovery design?

[jasonsetzer81-byte]

🏷️ Discussion Type

Question

Body

We run a small merchant's 4×6 shipping-label workflow on a Windows 11 laptop (4 GB RAM) and a Windows-installed Rollo thermal printer. Labels are bought individually in Shopify. An attended local downloader uses Shopify's native Print documents action so Shopify records the documents as Printed, saves the combined two-page label + packing-slip PDF, then a local queue validates it and submits one job to the Windows spooler. We keep separate states for Shopify Printed, PDF saved, Windows submission, and paper confirmed by the operator.

Observed failures: an older intake pass opened historical PDFs before checking its durable duplicate ledger and hit MemoryError; the laptop's C: drive also reached zero free bytes; Shopify's print dialog has sometimes stalled. We changed intake to skip receipted jobs before opening files and stream one PDF at a time. A supervised single-order test passed end to end, but we have not established reliable 10–50 order batch behavior. We looked at QZ Tray's printer-status API and PrintLatch's local durable queue; PrintLatch currently does not claim label-media support. The application code is private, though I can share a sanitized minimal reproducer if useful.

Five questions for people who have built local print agents or Shopify document workflows:

1. Is there a supported Shopify API/event path to obtain the combined 4×6 shipping label + packing slip and update Shopify's Printed document status after a label is purchased? If the native Print UI is required, how have you made its delayed modal/PDF handoff recoverable without blindly clicking Print again?
2. What durable state transitions and idempotency keys would you use across “Shopify Print clicked,” “PDF saved,” “Windows accepted job,” and “operator confirmed paper,” especially when the process crashes between any two steps? Which uncertain states must stop for review rather than auto-retry?
3. On a 4 GB Windows machine, what PDF validation/rendering/spool architecture keeps memory and disk bounded for roughly 50 two-page 4×6 jobs? Would you retain individual per-order jobs, combine them for throughput, or use a different approach while preserving per-order reconciliation?
4. Which Winspool, Windows PrintService, QZ Tray, or driver events can reliably correlate a unique order/fulfillment job with printer errors? Which events only prove Windows accepted the job, versus actual paper output on a Rollo-class thermal printer?
5. Which maintained open-source library or agent would you evaluate for this use case, and what minimum fault-injection tests would you run before calling it production-ready (browser timeout, disk full, printer offline, crash/restart, duplicate PDF, and 10/50-order batches)?

This post was drafted with AI assistance; the reported failures and one-order result were checked against local records and the operator's paper confirmation. No customer or order data is included.

Guidelines

• I have read and understood this category's guidelines before making this post.