🐛 Bug Description
In backend/routes/sync.py, the /sync-file endpoint calls get_user_by_telegram_id twice consecutively, but the first call's result is immediately overwritten by the second. This means a full Supabase database round-trip is made on every VS Code file save with zero effect on logic — the return value is silently discarded.
Since the endpoint already validates payload.telegram_id == _auth on line 19, both calls query the exact same telegram_id, making the first call completely redundant.
🔁 Steps to Reproduce
- Clone the repo and run the backend locally
- Register a user via the Telegram bot (
/start)
- Add a
print statement before each get_user_by_telegram_id call in routes/sync.py (lines 22–23)
- Trigger a file save from VS Code (fires
POST /sync-file)
- Observe two identical Supabase queries logged for a single sync event
✅ Expected Behavior
/sync-file should perform one database lookup per request to resolve the authenticated user — not two identical queries that return the same row.
❌ Actual Behavior
Two sequential calls to get_user_by_telegram_id are made with the same telegram_id. The first call's result is immediately overwritten on the very next line:
# routes/sync.py — lines 22–23
user = get_user_by_telegram_id(_auth) # ← result discarded
user = get_user_by_telegram_id(payload.telegram_id) # ← overwrites above
Because _auth and payload.telegram_id are guaranteed equal by line 19, this is a dead database call on the hottest endpoint in the system (fires on every VS Code save).
🌍 Environment
Field Value
OS Any (server-side bug)
VS Code version Any
GitPhone extension version Latest
Python version (if backend issue) 3.11+
📋 Additional Context
📎 Additional Context
Root cause: This appears to be a refactor artifact. The first call originally used _auth as a separate validation lookup. When the explicit payload.telegram_id != _auth guard was added (line 19), the first lookup became dead code but was never removed.
Proposed fix — single line removal:
diff
Step 1: Resolve user
- user = get_user_by_telegram_id(_auth)
user = get_user_by_telegram_id(payload.telegram_id)
if not user:
Impact: This doubles Supabase read load specifically on POST /sync-file — the endpoint triggered on every file save. No behavior changes are introduced by the fix.
I'm happy to submit a PR for this if confirmed. ✅
🐛 Bug Description
In
backend/routes/sync.py, the/sync-fileendpoint callsget_user_by_telegram_idtwice consecutively, but the first call's result is immediately overwritten by the second. This means a full Supabase database round-trip is made on every VS Code file save with zero effect on logic — the return value is silently discarded.Since the endpoint already validates
payload.telegram_id == _authon line 19, both calls query the exact sametelegram_id, making the first call completely redundant.🔁 Steps to Reproduce
/start)printstatement before eachget_user_by_telegram_idcall inroutes/sync.py(lines 22–23)POST /sync-file)✅ Expected Behavior
/sync-fileshould perform one database lookup per request to resolve the authenticated user — not two identical queries that return the same row.❌ Actual Behavior
Two sequential calls to
get_user_by_telegram_idare made with the sametelegram_id. The first call's result is immediately overwritten on the very next line:🌍 Environment
Field Value
OS Any (server-side bug)
VS Code version Any
GitPhone extension version Latest
Python version (if backend issue) 3.11+
📋 Additional Context
📎 Additional Context
Root cause: This appears to be a refactor artifact. The first call originally used _auth as a separate validation lookup. When the explicit payload.telegram_id != _auth guard was added (line 19), the first lookup became dead code but was never removed.
Proposed fix — single line removal:
diff
Step 1: Resolve user
user = get_user_by_telegram_id(payload.telegram_id)
if not user:
Impact: This doubles Supabase read load specifically on POST /sync-file — the endpoint triggered on every file save. No behavior changes are introduced by the fix.
I'm happy to submit a PR for this if confirmed. ✅