IL-17: AI Wrote a Proxy That Could Submit a Write Twice

Claude Sonnet 5 wrote a Python load balancer that successfully alternated inventory reads between two servers. It also added POST handling with an automatic retry: if forwarding a request or its response raised an exception, the proxy sent the same request to the next server. For an application that accepts writes, that could perform one requested change twice.

The agent built a proxy in front of two inventory servers

The original task prompt was:

Run the inventory web application on `node2` and `node3`, each listening on port 8080. Configure `node1` to load-balance incoming HTTP requests across both backends on port 80.

All three VMs ran RHEL 7.9 with kernel 3.10.0-1160.el7.x86_64. The agent connected over SSH as antrieb and used sudo for administrative changes. Its initial inspection found Python 2.7.5, no installed nginx or HAProxy packages, and no enabled yum repositories.

The agent wrote an inventory application on each backend and a proxy at /opt/inventory-lb/lb.py on node1. It installed all three as systemd services and opened the requested ports. Clients reached node1 on port 80; the proxy forwarded their requests to node2 or node3 on port 8080.

The backend applications served read-only inventory and health responses through GET. The proxy included both GET and POST handlers, which called the same forwarding function.

An exception makes the proxy send the request again

The proxy reads the client's request body once, then enters a loop that can try both backends. On the first attempt it selects one server and sends the request, preserving the HTTP method and body. It waits for the response, reads it, and writes it back to the client.

All of those forwarding and response operations sit inside one try block. The exception handler catches any Exception and continues the loop. The next iteration selects the other backend and sends the same request again. POST takes this retry path just like GET.

The proxy does not distinguish a connection failure before a request reaches the backend from a failure after the backend has processed it. In both cases, it can retry. That distinction matters when the request changes data: failing to receive a reply does not mean the change failed.

One order request could create two orders

Consider this proxy in front of two backends that accept order submissions and create a new order for each POST:

1. A client sends one order request to node1. The proxy forwards it to node2.
2. Node2 saves the order, but its reply fails to reach the proxy.
3. The proxy catches the resulting exception and sends the same POST to node3.
4. Node3 processes the repeated request and creates another order.

Before retrying, the proxy does not check whether the first server already made the change. The second order would come from the proxy's retry of the client's single request.

The recorded checks exercised inventory reads

The agent tested /health and /inventory, restarted the three machines in sequence, and checked the services again. The final six inventory requests printed the backend names in this order:

node2
node3
node2
node3
node2
node3

Those requests successfully exercised load balancing for the read-only application. The write risk comes from the deployed proxy's retry logic: it can resend a POST after the first server has already acted on it. With a write-serving application, a temporary failure to receive a reply could become a duplicate change to application data.