amal66 puts a ceiling on what the app will swallow

A round of plumbing work caps how much a single request can demand and keeps the system standing when something goes wrong.

infrastructuresecurity

amal66's fork tightens two limits most users never see until they fail. First, loading past chat history now comes back in measured pages rather than one open-ended dump - the system hands over a batch at a time instead of trying to return everything at once. Second, the fork caps how large an incoming request can be and adds catch-all handlers that record a clear diagnostic when something crashes instead of failing silently.

None of this changes what the product does. It changes how it behaves under stress: oversized or abusive requests can't quietly exhaust memory, and the inevitable crash leaves a useful trail instead of a shrug. It's part of a broader reliability pass across this fork, and it's the kind of guardrail teams usually add only after the first bad day.

So what Worth a look for anyone evaluating whether a Mike-based deployment will hold up in production rather than just in a demo.

View this fork on GitHub →

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?

Commits in this thread

2 commits from amal66/mike, oldest first. Source extracted verbatim from the harvested git log.

SHA	Subject	Author	Date
`f38ea30d`	fix(chapter-17): paginate chat history requests	Amal	2026-05-24	↗ GitHub
commit body Chapter: 17 - Resource limits. Plain-English map: Add `limit` and `before` cursor support to chat history loading so the API does not return an unbounded number of chats in one request. Why it matters: Unbounded endpoints are easy to misuse accidentally and easy to stress on purpose. Pagination keeps response sizes predictable. Principle: Public API reads should be bounded and page through large data sets. Precedent borrowed: Upstream PR #110. Upstream base: willchen96/mike@d39f580. Original local commit: b52b04f.
`8664afc9`	fix(chapter-18): bound JSON bodies and log process failures	Amal	2026-05-24	↗ GitHub
commit body Chapter: 18 - Operational guardrails. Plain-English map: Reduce the accepted JSON body size and add handlers that log unhandled promise rejections and uncaught exceptions. Why it matters: Large request bodies can create memory pressure. Unexpected crashes should leave useful logs so operators can understand what happened. Principle: Bound inputs and surface failures clearly. Precedent borrowed: The fork report's security-hardening cluster, where many forks added basic abuse and reliability guardrails. Upstream base: willchen96/mike@d39f580. Original local commit: d70fde7.

Capture this thread into my fork

Download a single Markdown prompt that tells Claude how to port every commit above into your working tree — adapting paths and structure to match your repo. Run it via claude -p < capture-thread-588.md from inside the repo you want the changes in.

⬇ Download capture-thread-588.md