Hey everyone, it's your friendly neighborhood senior dev here.
I'm 38, working as a full-time engineer during the week, and tinkering with AI-powered algorithmic trading bots on the weekends.
Today, I want to share a story about a subtle but potentially catastrophic bug I found in my bot.
Seriously, thank goodness I caught this before deploying with real capital.
The TL;DR: My Discord notifications for order confirmations weren't firing, and the culprit was a forgotten load across multiple Python scripts.
I think this is a pretty common pitfall when you're working on personal projects with several interconnected Python scripts.
What Happened: A "Silent Failure" Uncovered by DRY_RUN Over the weekend, I was running my usual DRY_RUN tests for my forex bot.
My bot's architecture splits responsibilities: handles strategy logic, and executes actual trades on the exchange.
Looking at the console logs, seemed to be working perfectly.
I saw logs like .
But the Discord notifications, which are supposed to arrive after an order, simply weren't showing up.
Initially, I thought it might be a Discord issue or just a delay.
But after 30 minutes, still nothing.
This felt wrong.
The thought of this happening with real money sent shivers down my spine: "I thought I placed the order, but it never went through." "I was sure I closed that position, but it's still open." Bugs in notification systems are notorious for creating these kinds of silent failures, and they're genuinely scary.
The Investigation: Aha!
Found You...
My first step was to isolate the problem.
I directly invoked , the script responsible for sending notifications.
It worked perfectly, sending a test message to Discord.
This strongly suggested the issue was upstream, likely within , which calls .
I took a closer look at 's logs.
And there it was: the webhook URL, which should have been passed to the notification function, was .
Bingo.
But why ?
I store my webhook URL in a file, and other scripts, like , were successfully reading it.
So I compared the code for and .
And I immediately spotted the difference.
At the beginning of , there was a clear call: However, , the script in question, was missing this call.
This meant that when I ran the entire flow starting from , would load the variables, making them available to .
But if I ran directly for testing, or if it was called from a different entry point, no one was loading the file.
Consequently, the webhook URL was never set, and notifications failed silently.
My code had an implicit dependency, and that's a dangerous path.
If this were a team project, it would definitely be caught in code review.
But when you're working solo, these kinds of things can easily slip through.
The Fix: Resolving Dependencies Where They're Used Once the cause was clear, the fix was straightforward.
I added to before calling the notification logic.
Before (simplified): In this setup, when the module initializes, returns , leading to a silent notification failure.
After (simplified): I used to ensure that the file is located correctly, regardless of the current working directory during execution.
This guarantees that can always find and load the webhook URL, no matter how it's invoked.
It's a fundamental principle, but it's always good to be reminded: code that depends on certain features (like environment variables) should take responsibility for resolving those dependencies (loading them) where they are used.
Key Takeaways and Lessons Learned This incident taught me three important lessons: DRY_RUN Tests Are God-Tier The value of discovering "normal-looking anomalies" without any financial cost is immense.
Things that look like they're working are the most dangerous.
Never skip DRY_RUN tests before production deployment.
Eliminate "Implicit Assumptions" Between Scripts When you split code into multiple files, it's easy to develop implicit assumptions like, "Oh, that other file will initialize it." For project-wide settings like , it's better design to explicitly load them at each entry point or at the beginning of the modules that rely on them.
Consider Assertions for Critical Operations While I caught this with logs, for even more robustness, it might be worth adding an assertion like right before critical operations like placing an order or sending a notification.
This can catch misconfigurations immediately.
Operating a personal bot is a continuous battle against these subtle bugs.
But each one I squash makes the system stronger.
It was another weekend where my bot got a little smarter.
Oji / AI Algo Trading Engineer X: @oji_ai_dev