docs: Add Common Pitfall #75 - Wrong year in SQL queries

CRITICAL LESSON LEARNED (Dec 8, 2025):
- Database has 2024 dates, current date is 2025
- Query 'WHERE exitTime >= 2024-12-07' matches Oct-Dec (247 rows)
- Should query 'WHERE exitTime >= 2025-12-07' (6 rows)
- Result: Reported -$1,616 loss instead of actual -$137.55 (12× inflation)
- User was RIGHT with $120.89 figure, AI agent wrong due to year mismatch

PREVENTION:
- Always use NOW() or CURRENT_DATE for relative queries
- Never hardcode year without verification
- Check row counts before declaring results
- Include YYYY-MM-DD in SELECT to catch mismatches
- Trust user's numbers when they dispute - verify query year first

This is a REAL MONEY system - wrong numbers = wrong decisions.
Drift tells the truth. User was right. Verify queries.
This commit is contained in:
mindesbunister
2025-12-08 08:57:24 +01:00
parent 148ff5f495
commit 9c58645029

View File

@@ -3005,6 +3005,56 @@ This section contains the **TOP 10 MOST CRITICAL** pitfalls that every AI agent
📚 **Full Documentation:** `docs/COMMON_PITFALLS.md` (73 pitfalls with code examples, git commits, deployment dates)
75. **CRITICAL: Wrong Year in SQL Queries - ALWAYS Use Current Year (CRITICAL - Dec 8, 2025):**
- **Symptom:** Query returns 247 rows spanning months when expecting 5-6 recent trades
- **Root Cause:** Database stores timestamps in 2024 format, AI agent queried '2024-12-07' instead of '2025-12-07'
- **Impact:** Reported -$1,616 total loss when actual recent loss was -$137.55 (12× inflation)
- **User Dispute:** "THE LOSS WAS NOT 63$ but 120,89$. where do you get those numbers from??"
- **Root Cause Analysis:**
* Database exitTime field contains dates like '2024-12-02', '2024-12-05', etc.
* AI agent wrote query: `WHERE "exitTime" >= '2024-12-07 00:00:00'`
* This matched ALL trades from Oct 2024 onwards (247 rows)
* Should have written: `WHERE "exitTime" >= '2025-12-07 00:00:00'`
* Current date is Dec 8, **2025**, not 2024
- **MANDATORY SQL Pattern - ALWAYS Check Year:**
```sql
-- WRONG: Hardcoded 2024 when current year is 2025
SELECT * FROM "Trade" WHERE "exitTime" >= '2024-12-07 00:00:00';
-- CORRECT: Use current year 2025
SELECT * FROM "Trade" WHERE "exitTime" >= '2025-12-07 00:00:00';
-- BEST: Verify current date first
SELECT NOW()::date as current_date; -- Check what year database thinks it is
-- SAFEST: Use relative dates (past 3 days)
SELECT * FROM "Trade" WHERE "exitTime" >= NOW() - INTERVAL '3 days';
```
- **Verification Before Reporting Numbers:**
1. Check row count - if querying "last 3 days" returns 247 rows, year is WRONG
2. Verify date range in results: `SELECT MIN("exitTime"), MAX("exitTime") FROM ...`
3. Use `TO_CHAR("exitTime", 'YYYY-MM-DD HH24:MI')` to see full dates including year
4. Cross-reference with context: User said "emergency today" → query should return TODAY's data only
- **Why This Matters:**
* **This is a REAL MONEY system** - wrong loss figures = incorrect financial decisions
* User was EXACTLY RIGHT with $120.89 figure (actual Dec 5-8 losses)
* AI agent gave wrong numbers due to year mismatch in query
* Wasted user time disputing correct figures
* User mandate: "drift tells the truth not you" - trust user's numbers, verify queries
- **Prevention Rules:**
1. ALWAYS use `NOW()` or `CURRENT_DATE` for relative date queries
2. NEVER hardcode year without verifying current year first
3. ALWAYS check row counts before declaring results accurate
4. When user disputes numbers, re-verify query year immediately
5. Include full YYYY-MM-DD in SELECT to catch year mismatches
- **Red Flags Indicating Year Mismatch:**
* Query for "recent trades" returns 100+ rows
* Date range spans months when expecting days
* User says "that's wrong" and provides different figure
* exitTime dates show 2024 but current date is 2025
- **Git commit:** [Document wrong year SQL query lesson - Dec 8, 2025]
- **Status:** ✅ Documented - Future AI agents must verify year in date queries
72. **CRITICAL: MFE Data Unit Mismatch - ALWAYS Filter by Date (CRITICAL - Dec 5, 2025):**
- **Symptom:** SQL analysis shows "20%+ average MFE" but TP1 (0.6% target) never hits
- **Root Cause:** Old Trade records stored MFE/MAE in DOLLARS, new records store PERCENTAGES