Timeout lab: make ambiguous requests visible before adding retries

Write down the outcomes your product must distinguish

Define separate outcomes for a complete answer, an explicit HTTP error, a transport failure with an unknown remote outcome, and a stream interrupted after partial output. Include the input identifier, model ID, elapsed time and whether any answer text reached the application.

Do not collapse all four into an empty string or a generic success flag. A user deciding whether to repeat a request needs to know whether there is already a partial result and whether additional spending might occur. Billing certainty cannot be inferred from a client-side exception alone.

Reproduce the boundary cases without inference

Run the companion clients against local fixtures. Make one response arrive normally, one return HTTP 429, and another return HTTP 503. Add a delayed response that exceeds the client’s waiting policy. For the streaming client, deliver a visible text fragment and then close the stream before its completion marker.

Assert that the application reports the intended state for each case and makes no second request automatically. Count requests at the fixture endpoint. The observable assertion is one attempt for each submitted item, rather than a log message claiming that retries are disabled.

Understand which timeout your client actually controls

In Node, an abort signal can stop the client from continuing its fetch operation, but it does not prove remote work was rolled back. In the Python example, urllib’s timeout applies to blocking operations; it is not a strict budget for the entire workflow.

Because the Python HTTP call runs through asyncio.to_thread, cancellation of the coroutine is not reliable termination of an already running worker operation. Keep that distinction visible when interpreting elapsed time, concurrency measurements and shutdown behavior. An application deadline and remote execution are different observations.

Make a later retry a separate decision

The lab clients deliberately avoid automatic retries, including after ambiguous timeouts and partial streaming output. Do not append a fresh generation to the old text as though it were a continuation. Preserve the incomplete result and let a deliberate rerun have its own attempt record.

For UncensuredAI’s uncensored models, published capacity is shared and HTTP 429 can occur without a guaranteed fixed RPM or TPM quota. If you later design bounded retry behavior for explicit rejections, consult current service guidance and test its request count and cost implications separately.

Apply the protocol to one small live request

Local failures demonstrate application behavior, not provider availability or actual billing. Real API execution can consume paid credit, including a separate request you choose to make after uncertainty. Pass the fixture checks, inspect the current API reference, and keep the first live experiment small. Record what happened without turning a local test into a claim about live service reliability.