libretech
7df72676c9
The PayPal SDK keeps the promise of its OAuth token for the lifetime of its Client, also when the token request failed. After one failed token request, as during the DNS outage, every later call failed with that same error and without a request until the process restarted: once DNS was back, the investigators' harness (scenario S7) saw 0 DNS lookups. The client had no timeout either: the SDK's default of 0 means none. PayPalApi now reaches PayPal through createPayPalClient (src/checkout/paypal-client.ts). It creates the SDK's Client and OrdersController through an injected factory on the first call, and anew after an error of the token request, an error without an answer from PayPal (network, DNS, timeout), 401 or 5xx. PayPal's other answers, such as 422, keep the client. A call that fails on a client that was replaced meanwhile leaves its successor alone. A replacement is logged as a warning with the error described. The client times out after 15 s. paypalClientConfiguration builds its configuration, with the logging of bodies and headers off. The tests use a fake factory that, like the SDK, keeps a failed token request per client, and count constructions and token requests. With the real SDK in the harness, S7 looks DNS up again and every Client is created with a timeout of 15000. Refs libretech/mp#71 Refs libretech/mp#67
libreshop/cms
Strapi-based content backend (catalogue, orders, customers).
Part of the libreshop toolkit. Image
published at git.librete.ch/libreshop/cms on every push to main
and on v* tags.
Source
This repo was extracted from mp/cms/ on 2026-04-29; mp was the
first concrete adapter consuming the toolkit. mp's compose.yml now
pulls git.librete.ch/libreshop/cms:<pin> instead of building locally.
Build locally
docker build -t libreshop/cms:dev .
Adapter contract
See docker-entrypoint.sh and Dockerfile for the runtime surface.
Adapters configure the component via env vars and bind-mounted volumes;
do not patch the running container or rely on internal paths.