We've (o11y team) been working on a charming dev tool to help detect a class of issues we've been dealing with lately.
flaplint (read more here) detected a few hotspots in the postgres charm that can cause unnecessary juju hook executions (thus possible service downtime + some performance overhead?).
I thought I'd share the the outcome with you if that sort of subtle bugs are causing issues for you as well!
flaplint · postgresql-operator main@9b17fd3d4e-dirty
../postgresql-operator/src/backups.py
✖ 1368:9 unordered collection · rendered → on-disk file · high confidence
`rendered` is an unordered collection written to an on-disk file without first being
sorted. Fix at the source: the instability is created upstream in `_peer_members_ips()`
(../postgresql-operator/src/charm.py:1042).
✖ 464:14 unsorted iteration into a sequence · backup_list → databag · medium confidence
`backup_list` is iterated without sorted() to build a sequence written to the relation
databag. Sort at the iteration (sorted(`backup_list`)), or annotate `backup_list` as
dict/list if callers already guarantee order.
../postgresql-operator/src/charm.py
✖ 275:9 nondeterministic value · timestamp → databag · high confidence
`timestamp` is freshly generated each time this code runs, so when this path executes
the value written to the relation databag differs from last time (sorting cannot fix
it). If that write is intentional, suppress it with `# databag-order: ignore`.
✖ 2285:9 unordered collection · self.relations_user_databases_map → on-disk file · high confidence
`self.relations_user_databases_map` is an unordered collection written to an on-disk
file without first being sorted. Fix at the source: the instability is created upstream
in `list_users()`
(../postgresql-operator/lib/charms/postgresql_k8s/v0/postgresql.py:706).
../postgresql-operator/src/cluster.py
✖ 726:9 unsorted iteration into a sequence · rendered → on-disk file · high confidence
`rendered` carries a value whose element order was baked in by an unsorted iteration,
before it reaches an on-disk file at ../postgresql-operator/src/cluster.py:636. Fix at
the source: the instability is created upstream in `_peer_members_ips()`
(../postgresql-operator/src/relations/async_replication.py:248).
✖ 726:9 unsorted iteration into a sequence · rendered → on-disk file · high confidence
`rendered` carries a value whose element order was baked in by an unsorted iteration,
before it reaches an on-disk file at ../postgresql-operator/src/cluster.py:636. Fix at
the source: the instability is created upstream in `relation.units()`
(../postgresql-operator/src/relations/async_replication.py:326).
../postgresql-operator/src/relations/db.py
✖ 163:21 unsorted iteration into a sequence · relation.units → databag · high confidence
`relation.units` is an unordered source iterated without sorted() to build a sequence
written to the relation databag at ../postgresql-operator/src/relations/db.py:432.
✖ 295:78 unsorted iteration into a sequence · unit → databag · high confidence
`unit` is an unordered source iterated without sorted() to build a sequence written to
the relation databag.
────────────────────────────────────────────────────────
✖ 8 flap risk(s) 8 yours · 26 file(s) scanned
We've (o11y team) been working on a charming dev tool to help detect a class of issues we've been dealing with lately.
flaplint (read more here) detected a few hotspots in the postgres charm that can cause unnecessary juju hook executions (thus possible service downtime + some performance overhead?).
I thought I'd share the the outcome with you if that sort of subtle bugs are causing issues for you as well!