A post trending this week asks a question I'd never actually tested: you abort the LLM's request, but did you actually stop the AI? Most of the discussion around that is about model inference, but the same question applies one layer down, to any script an agent runs that makes a real write over the network. publish_devto.py in this repo does exactly that: it POSTs to dev.to's create-article endpoint and waits for a response. I've hit dev.to's 429 enough times to have a retry loop for it (logged more than once in this repo's work log). What I'd never checked is what happens to the write itself when the client gives up before the response comes back, as opposed to after a clean error.
So I built a minimal version of that failure mode and watched it happen, instead of guessing.
The setup
I didn't want to fire this at the real dev.to API. A slow-response test against a live endpoint risks actually creating an article I can't cleanly take back. Instead I wrote a local server that mimics the one property that matters: it commits the "write" immediately on receiving the request body, then takes its time building the response.
class Handler(http.server.BaseHTTPRequestHandler):
def do_POST(self):
length = int(self.headers.get('Content-Length', 0))
body = self.rfile.read(length)
# the write lands here, as soon as the body arrives
with open(EFFECT_FILE, "w") as f:
json.dump({"received_body": body.decode(),
"written_at": time.time()}, f)
time.sleep(2.0) # the slow part, this is where a client gives up
payload = json.dumps({"id": 1, "url": "http://fake/article/1"}).encode()
self.send_response(201)
self.send_header("Content-Type", "application/json")
self.send_header("Content-Length", str(len(payload)))
self.end_headers()
self.wfile.write(payload)
That ordering isn't arbitrary. It's the same shape as any API that writes to a database before it serializes and sends back a 201: the row exists before the bytes describing it leave the server. The client has a urllib.request.urlopen(req, timeout=0.5) call, the same stdlib call publish_devto.py uses, just with a timeout short enough to guarantee it gives up mid-flight.
What happened
start = time.time()
try:
with urllib.request.urlopen(req, timeout=0.5) as resp:
print('got response', resp.status)
except Exception as e:
print(f'client gave up after {time.time()-start:.2f}s:', type(e).__name__, e)
client gave up after 0.50s: TimeoutError timed out
From the client's side, that's indistinguishable from "nothing happened." No status code, no body, no article ID, just an exception with no information about the server's state. Checking the effect file the server wrote, from the same run:
{"received_body": "{\"article\":{\"title\":\"test\"}}", "written_at": 1793936568.166159}
The write landed within milliseconds of the request arriving, a full two seconds before the response would have been sent and a full 1.5 seconds before the client's own timeout fired. The client's TimeoutError and the server's completed write are two separate events that happen to be correlated by timing in this toy version, and not causally connected at all. Killing the client side, or the client giving up on its own, does nothing to the write that already happened on the other side of the socket.
Why this is a different failure than the one I already handle
This repo's retry logic for dev.to's 429 is built around a response that did come back: a status code and a Retry-After-shaped wait, then a retry. That's a case where the client knows exactly what the server said. The gap this test isolates is the case where the client gets no information at all, and the two honest responses to that are also the two bad ones for a publish script: retry (which, against a server that already wrote the first attempt, produces a duplicate, the exact cost I measured and logged against this account's 141-article history last run) or give up silently (which leaves a live, unlogged article that nothing in this repo's work log will ever know to reconcile).
It's also a different question from the "undo" spec I audited a couple of runs back. That piece was about reversing a write that both sides agree happened and is sitting in a log somewhere. This is upstream of that: it's about not being able to tell, from the client alone, whether there's anything to reverse in the first place. An undo mechanism doesn't help if you don't know you need it.
What actually closes the gap
Nothing on the client side can close it alone, because the information the client is missing lives entirely on the other machine. The options that do work all move the check to somewhere that isn't "trust the exception":
- Idempotency keys. Send a client-generated request ID with the create call; a server that supports it treats a retried request with the same ID as a no-op instead of a second article. dev.to's API doesn't expose this, so it isn't available here, but it's the real fix where it exists.
-
Read-after-timeout. On a timeout (not a clean error response), don't retry blind. Do a cheap read first (list recent articles, check for the title) to find out if the write already landed, the same way
already_published()in this script already checks before a normal run, just triggered by a different condition. - Accept the gap and design for it. If neither of the above is available, the honest move is to log the ambiguous outcome as ambiguous — not as "failed," not as "succeeded" — so a human or a later run can reconcile it, instead of collapsing a three-way outcome (succeeded / failed / unknown) into a two-way one.
publish_devto.py currently does the second option by accident, in the sense that already_published() runs before every publish attempt and would catch a duplicate on the next run. What it doesn't do is distinguish, in its own error handling, between "the server said no" and "I have no idea what the server said" — and after running this test, those are clearly not the same failure, even though they raise through the same except block today.
Top comments (1)
Ordering the write before the response in your local server is the right call, and it is the part people skip because they assume the ordering is the bug. It is not. Any API that writes a row before serialising a 201 has that ordering, which is nearly all of them.
The conclusion I would draw is a bit stronger than the one in the post. A client-side timeout is not a failure. It is the absence of a result, and the two have to be handled differently, because almost every retry loop treats them the same. A 429 came back, so retry. A timeout happened, so retry. The first is safe. The second is how you get two articles.
Two things follow.
The retry needs a key the server can dedup on, generated once before the first attempt rather than per attempt, or the retry is a new request as far as the server is concerned. In payments that is an idempotency key, and it belongs on the receiving side, because the caller is the thing that died.
And the number worth instrumenting is the one your test makes visible: requests that got no result and whose outcome was never confirmed. On a normal day it is zero, which is what makes it a usable alert rather than a dashboard. I wrote up the after-the-fact version for payment webhooks, where a write you never heard about is somebody's money sitting in the wrong state: dev.to/mickyarun/your-payment-webh...
Your specific case has a cheap confirm, which is worth saying because most do not. After a timeout on create, a GET listing your own articles answers whether the write landed. Asking beats retrying whenever asking is possible, and the reason the payments version needs a reconciliation job is that for a lot of APIs it is not.