mrambossekandClaude Fable 5
3c9af04e6f
The live throughput test found it: a 3-second run delivered 104 packets and stopped after 50 milliseconds. The rate check exempted the first 50 ms entirely, meaning to be lenient at startup. The effect was the opposite. A sender could dump an unbounded burst into that free window, and the instant the check switched on it compared those bytes against 50 ms worth of allowance and refused everything until real time caught up. Every short test passed — downtrain sends 50 packets, big_send seven — and every sustained send died about fifty milliseconds in. A token bucket (allowance = burst + rate x elapsed) has no such cliff; it is smooth from t=0. The burst is 100 ms of the allowed rate, floored at one ordinary datagram so a single packet is never refused outright. The floor is deliberately one datagram: at 8 kbps a 64 KB floor would be sixty-four seconds' worth, which is precisely the instant dump the ceiling exists to prevent. The existing rate test caught that when I first tried it, and it was right. Second half of the same bug: callers treated any refusal as terminal. TryAllow now says why, so a sender can pace through a transient "too fast just now" and still stop dead on a spent budget or an expired grant. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>