Adds live coverage for three P0 logging-registry cells against a real proxy
and the real sinks: logging.s3.success.writes_object,
logging.s3.failure.writes_object and logging.datadog.failure.exports_metric.
The failure cases drive a genuine upstream rejection; each test registers a
deployment whose provider api_key is invalid, so OpenAI itself returns the
401 and litellm's failure path is what has to deliver. Delivery is then read
back out of the sink, never inferred from the proxy's own response: the s3
tests fetch the object with the AWS SDK and assert the stored payload's
status, model, cost and prompt, while the datadog test reuses the existing
logs-search reader and asserts the event's failure status alongside the
provider's error class, code and name. Every object a test writes is deleted
on teardown.
Both failure tests correlate on the x-litellm-call-id of the attempt they
accepted rather than on the prompt. A rejection at the gateway is logged as a
failure too, carrying the same prompt, so a virtual key that briefly 401s
before the auth cache catches up would otherwise contribute a second record
and turn the exactly-one assertion red on correct behavior.
A logging integration is a process-wide callback rather than a per-request
option, so callback_config.py lets a test declare the destination it needs:
it reads the registered callbacks back from /get/config/callbacks, registers
the missing one through /config/update, and unregisters exactly what it
registered afterwards. A proxy that already ships the integration is left
untouched. Every write is a read-modify-write of the live callback list, so
enabling or disabling a destination cannot clobber a registration made
concurrently by another test on the same proxy.
A read-modify-write is still not atomic and cannot be made so here, because
the config API offers only a whole-list write and a server-side
read-remove-write, with no per-entry update to compare-and-set against. Each
write therefore re-reads the list and fails, naming the entries, if anything
registered beforehand that belongs to someone else has gone, which turns a
silent change to a shared proxy's logging configuration into a diagnosable
failure. Entries that appear only after a write are a later registration
rather than damage and are left alone.
2090047bd3