vuer_oss supports multiple named RabbitMQ connections via @techteamer/mq’s ConnectionPool, and the optional-queue ECONNREFUSED swallow in server.ts (introduced by FKITDEV-3191) exists to keep boot alive when one of those connections — typically a partner’s external eSign RabbitMQ — is down. It looks like dead code from inside the repo because no in-repo config sets optional; partner runtime configs live outside the repo tree.

Do not delete this as dead code

An attempt to remove the optional handling as unreachable was made and reverted. Absence of a config key in the repo is not evidence the feature is unused — deployment configs are supplied per partner at runtime.

Evidence that multi-connection support is live

SiteWhat it does
vuer_oss/server.ts:465reads config.get('esign.queueConnection')
vuer_oss/background.ts:197reads config.get('esign.queueConnection')
vuer_oss/bin/attachment.js:52reads config.get('esign.queueConnection')

All three then call connectionPool.hasConnection() to decide whether the named connection exists. @techteamer/mq’s ConnectionPool accepts the named-map config shape (a map of connection name → connection settings) rather than a single connection object, which is what makes esign.queueConnection meaningful.

Why optional matters at boot

A partner may point eSign at a RabbitMQ broker they operate themselves. If that broker is down when vuer_oss starts, a non-optional connection attempt throws ECONNREFUSED and takes the whole process with it — supervisord then crash-loops the service even though the core product is perfectly healthy. Marking that connection optional swallows the connect error and lets boot proceed; the queue reconnects later.

For Agents

When auditing “unused” config keys in vuer repos, check whether the key is a partner runtime config knob. The repo ships config/*.json defaults only; real deployments layer partner config from outside the git tree (see customization-branches). Grep the readers of the key, not the setters.