Repository navigation
refactor: simplify error message formatting in exception handling #7881
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -78,9 +78,7 @@ def is_valid( | |
| if raise_exception: | ||
| raise AppApiException( | ||
| ValidCode.valid_error.value, | ||
| gettext("Verification failed, please check whether the parameters are correct: {error}").format( | ||
| error=str(e) | ||
| ), | ||
| str(e), | ||
| ) | ||
| return False | ||
|
|
||
|
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The change removes a translated, user-friendly message ("Verification failed, please check whether the parameters are correct: {error}") and replaces it with raw exception text Issues / irregularities:
Suggestions:
Minor: No functional bug introduced (exception type and code |
||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -91,9 +91,7 @@ def is_valid( | |
| if raise_exception: | ||
| raise AppApiException( | ||
| ValidCode.valid_error.value, | ||
| gettext("Verification failed, please check whether the parameters are correct: {error}").format( | ||
| error=str(e) | ||
| ), | ||
| str(e), | ||
| ) | ||
| return False | ||
|
|
||
|
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Looking at this diff, here are the observations: Potential Issues1. Loss of Context / Localization RegressionThe biggest concern is losing user-friendly context. The original message:
The new version returns only
2. Raw Exception Messages Leaking to Clients
3. Inconsistent Error ContractOther branches of 4.
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Review of the diff
1. Functional issue / fragile substring match
if "bge" in model_id:uses a plain substring check on the raw string. This is case-sensitive and unanchored, so it will:BGE-M3,BGE-Large.bgeas part of another token (e.g....subgemini..., vendor prefixes, version suffixes). Low probability today, but brittle.Suggested: normalize and use a clearer token match, e.g.
2. Ordering dependency is implicit and undocumented in code structure
The comment explains why
bgefollowsrerank, which is good, but the correctness now relies entirely on statement order. If someone later reorders or adds another prefix check (e.g."m3" → EMBEDDING, or movingembeddingchecks),bge-reranker-*could regress silently. Consider making the reranker exclusion explicit:This makes intent self-contained and order-independent.
3. Consistency with existing style
Other branches use
any(k in model_id for k in (...)). A single-entry tuple is unnecessary; a plainincheck is fine. But mixing styles may invite future inconsistencies — acceptable as-is.4. No test coverage shown
Since this changes classification of a whole model family (
bge-small,bge-m3,bge-large, and criticallybge-reranker-*), add unit tests asserting at minimum:bge-m3→ EMBEDDINGbge-reranker-v2-m3→ RERANKER (regression guard)bgedoes not get misrouted if relevant.5. Coverage gap (not caused by this diff)
bgeis ForceAI/BAAI naming; other embedding families (e.g.gte,e5,m3e,jina-embed,text-embedding) aren't handled. If the goal is general robustness, consider a shared constant list rather than ad-hoc branches.No blocking bugs — the change works for the documented cases. Main risks are the case-sensitive/unanchored match and the order-dependent logic.