fix(pskr): backfill pods opt out of MQTT client by default

Both `prop` and `prop-backfill` deployments use `app=prop` for the
libcluster selector, so they share a :global namespace. During a
rollout the backfill pod can win FCFS leader election and end up
running the real-time MQTT client on the same pod that's churning
through batch enrichment jobs. Worse, the backfill pod was still
running the pre-IPv4-fix image and surfacing :einval on every
30-second retry.

Gate `pskr_mqtt_enabled` off when PROP_ROLE=backfill. Explicit
PSKR_MQTT_ENABLED=true still wins if you ever want to flip it on
for a dedicated MQTT pod.
This commit is contained in:
Graham McIntire 2026-05-04 10:23:04 -05:00
parent fb503ed2e7
commit 1f021f42e6
No known key found for this signature in database
GPG key ID: F4ABF488E6029E59

View file

@ -383,12 +383,24 @@ if config_env() == :prod do
# cluster-elected leader actually connects (`:global` registration
# in `Microwaveprop.Pskr.Client`). Set `PSKR_MQTT_ENABLED=false`
# to kill the entire feature without code change.
#
# Backfill pods opt out unconditionally — they share the libcluster
# `app=prop` selector with the hot pods, so without this gate the
# backfill pod can win :global election (FCFS during a rollout)
# and pin the MQTT client onto a node that's also under heavy
# batch-job load. MQTT is real-time; backfill is bursty CPU; the
# two don't mix on the same pod.
pskr_default = prop_role != "backfill"
case System.get_env("PSKR_MQTT_ENABLED") do
disabled when disabled in ["0", "false", "FALSE"] ->
config :microwaveprop, :pskr_mqtt_enabled, false
_ ->
enabled when enabled in ["1", "true", "TRUE"] ->
config :microwaveprop, :pskr_mqtt_enabled, true
_ ->
config :microwaveprop, :pskr_mqtt_enabled, pskr_default
end
# Optional secondary repo for read-only access to aprs.me's database.