How to preserve printer UUID/ID across restarts in cups-browsed to avoid job loss in Kubernetes with PVC

We are running a CUPS setup inside Kubernetes, where printers are dynamically discovered using cups-browsed and we persist important CUPS directories across pod restarts using PVCs (/etc/cups/printers.conf and /var/spool/cups).

Our issue arises when the client pod is deleted and recreated:

The printer UUID/ID changes in printers.conf, even though the printer name remains the same.

The print jobs retained in /var/spool/cups no longer get processed because they are no longer linked to the new printer instance.

This leads to jobs stuck in the spool with “[“No suitable Destination Host found by cups-browsed]” issues or silent failures.

From the CUPS maintainer's response, we understand that:

https://github.com/OpenPrinting/cups/discussions/1245

Print jobs on the client side can be affected by changes in printer UUID/ID.

cups-browsed can delete and recreate queues, which in turn breaks job associations.

Is there a recommended way in cups-browsed to persist or reuse the same printer UUID or ID across restarts in Kubernetes?
Alternatively, is there a way to avoid deleting/replacing queues if the discovered printer matches a previously seen printer (e.g., by hostname/IP/DeviceURI), so that queued jobs remain valid?

Our goal is to ensure that jobs in the spool directory can continue printing after a pod restart, especially in high-availability or clustered environments.

The issue identifies /etc/cups/printers.conf and /var/spool/cups; begin by tracing cups-browsed's discovered-queue lifecycle and how CUPS associates queued jobs with printer IDs across pod restarts. Done would require an agreed persistence or queue-reuse behavior plus validation that retained jobs resume after restart, but no test or entry point is named here.