@Arjan nothing is misconfigured on your side. Ledger identifies a sender by the source IP of the request, and inside Kubernetes that is the pod IP, so every restart of the web or task pod arrives as a server it has never seen before.
From parse.php in ascender-ledger: the servers table has a unique key on ip, an unknown address gets a row with trusted at 0, and that first payload is dropped rather than held. That is the other half of what you are seeing, the facts that never arrive: whatever a pod sent before you clicked the lock is gone rather than queued. Trust is a flag on the row, so there is no subnet to approve and no switch that turns approval off.
Two things you can do today, both in the database rather than the interface:
- Pre-approve the pod subnet: one row per address,
trusted set to 1, so a new pod lands on an approved row.
- Or trust new senders on sight:
ALTER TABLE servers ALTER COLUMN trusted SET DEFAULT 1.
The second only makes sense where the parser port cannot be reached from outside the cluster, and it keeps the server names right: name is written when the parser creates a row and never updated, so rows you seed by hand stay blank, and the interface has no field to name them.
Either way the first message from a new address is lost, since the insert path exits before recording it.
The real fix is for Ledger to key on something stable in the payload instead of on the socket. Ascender already sends tower_uuid, its install identifier, with every record, and that survives a pod being rescheduled where an address does not. Trusting on that, or accepting a CIDR, is what would make this work properly on Kubernetes. Say the word and I will open it as an issue on the repository with your case as the example.
