The Lost Weekend, Part 3 of 4, or debugging with Gemini a prototype that Claude threw together:
May 31, early
What did it mean?
AssertionError: None
Six hours later, I finally understood what that error was trying to tell me: Stop.
The mystery that made no sense
PyGithub was throwing assertion errors on GitHub issue creation. The debugging logs showed everything was valid:
- Labels array:
['feature', 'enhancement', 'prototype', 'priority']- only 4 items, well under the 100 limit - Repository access: confirmed working
- Authentication: valid token with proper permissions
- Input parameters: all properly formatted
Yet somehow: assert len(labels) <= 100 was failing with AssertionError: None.
Seven bugs on the way to nowhere
Here’s the thing about chasing mysterious bugs — you find other bugs along the way. Saturday’s rabbit hunt netted:
- ✅ Milestone assertion fix
- ✅ Repository configuration correction
- ✅ Knowledge base context retrieval optimization
- ✅ Dependency version alignment
- ✅ JSON parsing robustness improvements
- ✅ Error message user-friendliness
- ✅ GitHub API method corrections
All real improvements. All valuable fixes. All distractions from the one bug that refused to make sense. Do you know how frustrating it is to fix bug after bug after bug only to find you still haven’t gotten to the root of the problem.
This was when I started wondering why the code was so sloppy from the get-go.
The moment of clarity
Six hours in, debugging fatigue set in. That’s when the real insight hit:
I wasn’t debugging a bug anymore. I was debugging my debugging.
The AssertionError wasn’t a technical problem — it was a process problem. I was grinding when I should have been stepping back.
Strategic retreat
Sometimes the most productive debugging action is knowing when to stop debugging.
The seven bugs I’d fixed were real value. The mystery bug was a rabbit hole that could consume infinite time without guaranteed resolution.
Strategic decision: revert to the last working version. Start fresh with lessons learned.
To be honest. This felt like giving up. I was reluctant to back down after investing hours on fixing this one issue. That’s called the “sunk-cost fallacy,” kids!
The wisdom of walking away
Here’s what every debugger learns eventually: not every problem needs to be solved right now. Some problems need fresh eyes, clean environments, or just time to reveal their true nature.
The mysterious PyGithub error? Probably environmental. Possibly a library version edge case. Maybe even a cosmic ray flipping a bit somewhere.
But definitely not worth another six hours on a Saturday.
The real bug
The real bug wasn’t in PyGithub — it was in my process. Six hours of grinding when twenty minutes of fresh perspective might have solved everything.
Good debugging isn’t about persistence. It’s about knowing when persistence becomes counterproductive.
The best debuggers know when to stop debugging.