pit: raise the paste ceiling to 1000 and stop on the clock, not a count - #143
Merged
Conversation
A real paste hit the old cap: 195 claimed, "389 past the 200 limit, not attempted" — and nothing said what to do about the 389. Two changes. The ceiling goes 200 -> 1000, but it is no longer the thing that usually stops a paste. Claiming now runs against a 20s budget and stops when the budget is spent. A count cannot know how slow the database is today; the failure it was guarding against was a request dying halfway with no report of what landed, and a clock guards that directly. A fast database gets through hundreds, a slow one stops early, and neither ends as a timed-out request whose result nobody sees. The budget is checked before each write and never before the first, so an already-slow database still claims one rather than reporting a paste that did nothing and looks broken. Whatever is left is now named and actionable: "N not attempted — paste them again to carry on", covering both the over-ceiling and out-of-time cases, which are the same problem from the user's side. Caught while testing: the single-ending shortcut in summarizeBulkClaim did not know about leftovers, so one claim plus four unattempted reported as ".x is yours." and silently lost the four. 6 more tests. 262 across the pwa suite. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
vu1nz Security Review0 finding(s) in PR #? No security issues found. |
The hint interpolates the ceiling, so raising it to 1000 made the line read "Up to 1000 at a time." A ceiling is a rough promise and should read like one. Only exact thousands are shortened. 1500 stays 1500, because "1.5k" reads as an approximation of a number that is exact, and the whole point of the line is telling someone where the limit actually is. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Merged
ralyodio
added a commit
that referenced
this pull request
Jul 31, 2026
* chore(release): v0.13.3 install.sh resolves releases/latest, so everything merged since v0.13.2 has been sitting on main unreachable — `moshcode dns enable` exists in the source and not in anyone's binary. The headline is the DNS bridge (#141). Moshpit names now resolve for every program on the machine, not just inside TronBrowser: each OS gets the mechanism that routes ONE SUFFIX rather than the one that replaces the resolver — /etc/resolver on macOS, systemd-resolved routing-only domains or dnsmasq on Linux, an NRPT rule per namespace on Windows. moshcode dns enable / disable / status moshcode uninstall <engine|tool> (#150, completion in #151) The pit gained most of a namespace registry in between: key pins per name (#137), pasted bulk claiming with per-line price and target (#138, #142, #143, #146), all-numeric endings (#147), /n/<name> serving a name or a directory (#145, #149), and Buy Now on an unclaimed name (#148). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * chore: restore the em-dash the version bump escaped The bump rewrote package.json through a JSON serialiser that defaults to ASCII, turning the em-dash in `description` into —. Valid JSON and the same string once parsed, but a gratuitous diff in a commit that should touch one line. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #142 — this commit was pushed to that branch after it merged, so it never landed.
Why
A real paste hit the old cap:
Nothing said what to do about the 389.
Two changes
Ceiling 200 → 1000. But the count was never the right guard. Each claim is one sequential INSERT against a remote database, and what the cap actually protected against was a request dying halfway with no report of what landed.
Claiming now runs against a 20-second budget and stops when it's spent. A count can't know how slow the database is today; a clock guards the real failure directly. Fast database gets through hundreds, slow one stops early, neither ends as a timed-out request whose result nobody sees.
Checked before each write and never before the first — an already-slow database still claims one, rather than reporting a paste that did nothing and looks broken.
Leftovers are named and actionable:
N not attempted — paste them again to carry on, covering both the over-ceiling and out-of-time cases, which are the same problem from the user's side.A bug the tests caught
The single-ending shortcut in
summarizeBulkClaimdidn't know about leftovers, so one claimed + four unattempted reported as.x is yours.and silently lost the four.Tests
6 new. 262/262 across the pwa suite.
🤖 Generated with Claude Code