From 1f021f42e631891e08508d735a758aacbde1ebd2 Mon Sep 17 00:00:00 2001 From: Graham McIntire Date: Mon, 4 May 2026 10:23:04 -0500 Subject: [PATCH] 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. --- config/runtime.exs | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/config/runtime.exs b/config/runtime.exs index c6473cbe..f2578331 100644 --- a/config/runtime.exs +++ b/config/runtime.exs @@ -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.