Auto: refactor/code-review-fixes #28
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "refactor/code-review-fixes"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Automated PR for branch
refactor/code-review-fixes.Approved
A well-structured refactoring that introduces a database singleton (
_db), addsread_onlyconnection optimization, defers bot initialization to ASGI lifespan, extracts helper functions to eliminate duplication, and fixes real bugs (off-by-one rate limiting, O(n²) truncation, TOCTOU in feedback state). All retry loop paths were verified to be exhaustive (aided by a catch-allexcept Exceptionin both functions), and theBEGIN EXCLUSIVEinactivate_premiumcorrectly prevents race conditions from duplicate payment webhooks. No critical or warning-level issues found.Suggestions
_perform_single_model_translationand_perform_streaming_translation, both functions lack a return statement after theforloop. This is safe at runtime (every loop iteration returns, and MAX_ATTEMPTS=3), but static analyzers like mypy cannot prove the loop body always returns and may flag a missing return type. Consider adding a defensivereturn S.GENERIC_ERROR, 0, 0, 0or anassert False, 'unreachable'after each loop for type-checker clarity._db(underscore-prefixed, conventionally private) yet it is imported across multiple modules (admin_dashboard.py,webhook.py). This works fine but is a slight API signal mismatch. If it's intended as the public entry point for raw DB access, consider naming itdb; if raw access should remain discouraged, the current naming is appropriate — just noting the inconsistency.read_onlyparameter onget_connection()controls whethercommit()is called but doesn't prevent DML execution. This is reasonable (enforcing true read-only would be over-engineering), but a brief note in the docstring like 'Caller is responsible for not issuing DML when read_only=True' would clarify intent for future contributors.activate_premium, the explicitconn.execute('BEGIN EXCLUSIVE')is a good addition for preventing race conditions. Minor note: with Python's sqlite3 legacy transaction control (isolation_level=""), this works correctly because PRAGMAs don't trigger implicitBEGIN. If the project ever switches toautocommit=True(Python 3.12+), this code would need no changes since explicitBEGINis the expected pattern in that mode.