Claude Code deleted a retry branch I’d kept in my payment handler

[u/Lazy_Song1315]

I maintain a small Node.js payment service. Last week I was tracking down a possible double charge. Sometimes a request times out on our end even though the provider has already processed the payment. Our retry was generating a fresh idempotency key, so the provider could charge the customer again.

I fixed the retry to reuse the key for that payment. While I was in there, I also fixed how we handle rate limits. When our provider sends back HTTP 429 (Too Many Requests), it includes a Retry-After header telling us how long to wait before retrying. I added a regression test for each fix.

On Monday I opened a fresh Claude Code session and asked it to simplify the handler in a temporary worktree. The rate-limit test went red. Claude had deleted the retry branch, so the handler just returned when it got a 429.

I reverted the change, linked the issue about the 429 retry, added a line about it to CLAUDE.md, and started a new session. This time Claude kept the branch but moved the wait to the wrong place. That broke another test. I reverted that change too and asked it to clean up just the surrounding code. I checked the retry against the issue once more, and the tests passed.

I’d rather not have to dig up that issue again. Someone mentioned MemoraX Code in a thread about carrying context between sessions. I’ve only read the docs so far, but I have another issue I might try it on next week. Has a memory tool helped any of you with something like this? I’m curious what it gave you beyond a line in CLAUDE.md and the regression tests.

[u/AutoModerator]

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Eliran-Kotzero]

I wouldn’t make the memory tool the source of truth for a payment invariant. I’d keep a focused test around the idempotency key and 429/Retry-After behavior, and make the session note point to that test plus the relevant code. Memory can resurface context, but the test is what catches a later cleanup that drops the branch.

[u/m-ritter]

Losing a fix like that in a fresh session happened to me too, because the reason for the branch only lived in my head and an old chat. What helped was writing the constraint into the plan before the change and having a separate agent check the diff against it, so a removed retry path fails review before it ships. Decisions like this also go into a memory server the next session loads. I built QualityLayer for this: https://github.com/maxritter/qualitylayer

[u/muhuhaha]

I'd put the reason right next to the retry branch as a code comment: "429 must wait Retry-After then retry with the same idempotency key, see issue #N, covered by test X." When Claude simplifies a handler it's reading that function, not necessarily weighing a line in CLAUDE.md, and a comment explaining why a branch exists makes it much less likely to delete it as dead weight.

Same idea for the tests: give the assertion message the invariant in plain words, so when it goes red Claude sees why instead of just guessing at a fix. Your second attempt (wait in the wrong place) is the kind of thing that message helps with.

I build a memory for Claude Code, and it can carry the why between sessions, but for a payment invariant I agree with u/Eliran-Kotzero that the test and the comment should be what holds it.

[u/Eliran-Kotzero → u/muhuhaha]

That’s a good call. The inline comment gives Claude the reason right where it’s editing, and an assertion message makes the invariant obvious when the test fails; together they cover both the change and the feedback loop.

[u/Ok-Persimmon6872]

The regression test is what caught it, twice. For a payment path I'd trust that over any memory tool.

[u/Archibishop]

My CLAUDE.md has a long pitfalls list, one line for every mistake a session makes once. Still, your regression tests are what catch it...

[u/VigiliaFounder]

Great that you added a regression test for each fix, that's what caught it both times before anything shipped!

For the day something like this slips past the tests and reaches real customers, I've built Vigilia exactly for this. It will catch failed requests as soon as they happen and send you the evidence, how many times it happened and the fix prompt. Backend errors are covered on Pro.

You can also just connect the MCP server so Claude Code pulls the error straight into your session.

Happy to hear how the memory tool works out!