python-barbicanclient — Async processing

Processing outside commands — python-barbicanclient — branch stable/2026.2

Branch stable/2026.2 @ 8162006e8677 — repository https://opendev.org/openstack/python-barbicanclient — analysed on 2026-11-01

None. The inventory found 0 triggers and 0 RPC calls, and reading the code confirms it: no bus consumer, timer, event listener or background thread. The library is called by a short-lived process (openstack, barbican) or by its host application. It keeps no state on disk.

Requests run one after the other, in the calling thread. What looks like background work is lazy loading: reading a property of a Secret, Container or CA can send a GET.

Process	Trigger	Type	Purpose	Reads	Writes / emits	Defined at
any caller	read of a lazy property of `Secret`	synchronous GET, repeated while the secret has no name	fill the fields	`GET /secrets/{id}`	none	`barbicanclient/v1/secrets.py:30`, `barbicanclient/v1/secrets.py:467`
any caller	read of a lazy property of `CA`	synchronous GET, repeated until `plugin_name` is set	fill the fields	`GET /cas/{id}`	none	`barbicanclient/v1/cas.py:27`, `barbicanclient/v1/cas.py:172`
any caller	read of `Container.name` or `Container.status` when empty	synchronous GET	fill the fields	`GET /containers/{id}`	none	`barbicanclient/v1/containers.py:127`, `barbicanclient/v1/containers.py:141`, `barbicanclient/v1/containers.py:235`
any caller	read of `Secret.payload` when empty	synchronous GET	fetch the plaintext	`GET /secrets/{id}/payload`	none	`barbicanclient/v1/secrets.py:232`, `barbicanclient/v1/secrets.py:312`

What the client leaves to the user

Orders are processed asynchronously by the service, but the client never waits:

secret order create sends the POST, keeps order_ref, and prints Status None (barbicanclient/v1/orders.py:208) [observed]. There is no --wait.
The user polls secret order get until ACTIVE or ERROR. The polling loop exists only in castellan (castellan:castellan/key_manager/barbican_key_manager.py:557).

Retries and timeouts

The client sets no retry and no timeout. keystoneauth retries once after a new token on a 401 when the request carries a token (keystoneauth1:keystoneauth1/session.py:1130): 2 requests [observed]. connect_retries defaults to 0 (keystoneauth1:keystoneauth1/session.py:408).
Requests are not idempotent by design: POST /secrets/ is not retried, and a failure after the server stored the secret leaves it in place, with an error on the client [inferred].

Source: reverse-spec-python-barbicanclient/05-async-processing_stable-2026.2.md. The _rewrite/ and _inventory/ files are not published on the site.