trustgraph/trustgraph-flow/trustgraph/flow/service
cybermaggedon 7521e152b9 fix: uuid-ify flow-svc ConfigClient subscription to avoid Pulsar ConsumerBusy on restart (#843)
flow-svc's long-lived ConfigClient was constructed with
subscription=f"{self.id}--config--{id}", where id=params.get("id") is
the deterministic processor id.  On Pulsar the config-response topic
maps to class=response -> Exclusive subscription; when the supervisor
restarts flow-svc within Pulsar's inactive-subscription TTL (minutes),
the previous process's ghost consumer still holds the subscription
and the new process's re-subscribe is rejected with ConsumerBusy,
crash-looping flow-svc.

This is a v2.2 -> v2.3 regression in practice, but not a change in
subscription semantics: the Exclusive mapping for response/notify is
identical between releases.  The regression is that PR #822 split
flow-svc out of config-svc and added this new, long-lived
request/response call site — the new site simply didn't follow the
uuid convention used by the equivalent sites elsewhere
(gateway/config/receiver.py, AsyncProcessor._create_config_client).

Fix: generate a fresh uuid per process instance for the subscription
suffix, matching that convention.
2026-04-22 15:17:56 +01:00
..
__init__.py Flow service lifecycle management (#822) 2026-04-16 17:19:39 +01:00
__main__.py Flow service lifecycle management (#822) 2026-04-16 17:19:39 +01:00
flow.py feat: workspace-based multi-tenancy, replacing user as tenancy axis (#840) 2026-04-21 23:23:01 +01:00
service.py fix: uuid-ify flow-svc ConfigClient subscription to avoid Pulsar ConsumerBusy on restart (#843) 2026-04-22 15:17:56 +01:00