update VerificationErrorType and VerificationStatus#310
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
✱ Stainless preview buildsThis PR will update the kotlin openapi python typescript
|
| - IN_PROGRESS | ||
| - APPROVED | ||
| - REJECTED | ||
| - READY_FOR_VERIFICATION |
There was a problem hiding this comment.
We do not auto-submit on behalf of the customer after they've resolved all the verification errors. This is why we need this intermediary verification status.
Greptile SummaryThis PR expands the verification schema by adding a new
Confidence Score: 5/5Safe to merge — all changes are additive enum expansions with no breaking changes and both generated bundles are correctly re-bundled All findings are P2 style/description improvements. There are no logic errors, breaking schema changes, or missing consistency between source files and generated bundles. The new enum values are purely additive. openapi/components/schemas/verifications/VerificationErrorType.yaml — minor description clarity improvements worth considering before this becomes a stable public contract
|
| Filename | Overview |
|---|---|
| openapi/components/schemas/verifications/VerificationErrorType.yaml | Adds 10 new error type enum values (document quality, fraud, and applicant-level errors) and updates the description; description has minor clarity issues around SUSPECTED_FRAUD_DOCUMENT categorization and APPLICANT_REJECTED coverage |
| openapi/components/schemas/verifications/VerificationStatus.yaml | Adds READY_FOR_VERIFICATION as a new verification status; change is clean and consistent |
| openapi/components/schemas/webhooks/WebhookType.yaml | Adds VERIFICATION.READY_FOR_VERIFICATION webhook type, consistent with the new VerificationStatus enum value and the existing VERIFICATION.* pattern |
| openapi.yaml | Generated bundle correctly reflecting all source changes; matches openapi/ source files as expected |
| mintlify/openapi.yaml | Generated Mintlify bundle correctly reflecting all source changes; matches openapi.yaml bundle |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart TD
A([Start]) --> RFV[READY_FOR_VERIFICATION\n🆕 new]
RFV --> IP[IN_PROGRESS]
IP --> PMR[PENDING_MANUAL_REVIEW]
IP --> RE[RESOLVE_ERRORS]
IP --> APR[APPROVED]
IP --> REJ[REJECTED]
PMR --> APR
PMR --> REJ
PMR --> RE
RE --> IP
APR --> Z([End ✅])
REJ --> Z2([End ❌])
style RFV fill:#d4edda,stroke:#28a745,color:#000
style APR fill:#cce5ff,stroke:#004085,color:#000
style REJ fill:#f8d7da,stroke:#721c24,color:#000
Prompt To Fix All With AI
This is a comment left during a code review.
Path: openapi/components/schemas/verifications/VerificationErrorType.yaml
Line: 24-29
Comment:
**`SUSPECTED_FRAUD_DOCUMENT` mislabeled as a "quality" type**
The description groups `SUSPECTED_FRAUD_DOCUMENT` under "Document quality types," but fraud detection is fundamentally different from quality issues like poor resolution or unreadability. API consumers may be confused or implement incorrect handling if they treat fraud detection the same as quality problems. Consider splitting the description into distinct categories.
```suggestion
description: >-
Type of verification error. The category-specific MISSING_*_DOCUMENT types
indicate which document category is needed. Document quality types
(POOR_QUALITY_DOCUMENT, WRONG_DOCUMENT_TYPE, INCOMPLETE_DOCUMENT,
UNREADABLE_DOCUMENT, DOCUMENT_VERIFICATION_FAILED) indicate specific
issues with uploaded documents. Fraud types (SUSPECTED_FRAUD_DOCUMENT)
indicate suspected fraudulent documents. APPLICANT_* types indicate issues
with the applicant themselves (sanctions, fraud, criminal records, general
rejection).
```
How can I resolve this? If you propose a fix, please make it concise.
---
This is a comment left during a code review.
Path: openapi/components/schemas/verifications/VerificationErrorType.yaml
Line: 24-29
Comment:
**`APPLICANT_REJECTED` undescribed in description**
The description's parenthetical for `APPLICANT_*` types lists "(sanctions, fraud, criminal records)" but omits `APPLICANT_REJECTED`. It's unclear from the description alone whether `APPLICANT_REJECTED` is a catch-all for when no more specific `APPLICANT_*` reason applies, or if it serves a distinct purpose. API consumers won't know when to expect this value vs the more specific types. Adding a brief note (e.g., "or general rejection") would remove the ambiguity.
How can I resolve this? If you propose a fix, please make it concise.Reviews (1): Last reviewed commit: "update VerificationErrorType and Verific..." | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| description: >- | ||
| Type of verification error. The category-specific MISSING_*_DOCUMENT | ||
| types indicate which document category is needed and determine the | ||
| accepted document types returned in acceptedDocumentTypes. | ||
| Type of verification error. The category-specific MISSING_*_DOCUMENT types | ||
| indicate which document category is needed. Document quality types | ||
| (POOR_QUALITY_DOCUMENT, SUSPECTED_FRAUD_DOCUMENT, etc.) indicate specific | ||
| issues with uploaded documents. APPLICANT_* types indicate issues with the | ||
| applicant themselves (sanctions, fraud, criminal records). |
There was a problem hiding this comment.
SUSPECTED_FRAUD_DOCUMENT mislabeled as a "quality" type
The description groups SUSPECTED_FRAUD_DOCUMENT under "Document quality types," but fraud detection is fundamentally different from quality issues like poor resolution or unreadability. API consumers may be confused or implement incorrect handling if they treat fraud detection the same as quality problems. Consider splitting the description into distinct categories.
| description: >- | |
| Type of verification error. The category-specific MISSING_*_DOCUMENT | |
| types indicate which document category is needed and determine the | |
| accepted document types returned in acceptedDocumentTypes. | |
| Type of verification error. The category-specific MISSING_*_DOCUMENT types | |
| indicate which document category is needed. Document quality types | |
| (POOR_QUALITY_DOCUMENT, SUSPECTED_FRAUD_DOCUMENT, etc.) indicate specific | |
| issues with uploaded documents. APPLICANT_* types indicate issues with the | |
| applicant themselves (sanctions, fraud, criminal records). | |
| description: >- | |
| Type of verification error. The category-specific MISSING_*_DOCUMENT types | |
| indicate which document category is needed. Document quality types | |
| (POOR_QUALITY_DOCUMENT, WRONG_DOCUMENT_TYPE, INCOMPLETE_DOCUMENT, | |
| UNREADABLE_DOCUMENT, DOCUMENT_VERIFICATION_FAILED) indicate specific | |
| issues with uploaded documents. Fraud types (SUSPECTED_FRAUD_DOCUMENT) | |
| indicate suspected fraudulent documents. APPLICANT_* types indicate issues | |
| with the applicant themselves (sanctions, fraud, criminal records, general | |
| rejection). |
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/verifications/VerificationErrorType.yaml
Line: 24-29
Comment:
**`SUSPECTED_FRAUD_DOCUMENT` mislabeled as a "quality" type**
The description groups `SUSPECTED_FRAUD_DOCUMENT` under "Document quality types," but fraud detection is fundamentally different from quality issues like poor resolution or unreadability. API consumers may be confused or implement incorrect handling if they treat fraud detection the same as quality problems. Consider splitting the description into distinct categories.
```suggestion
description: >-
Type of verification error. The category-specific MISSING_*_DOCUMENT types
indicate which document category is needed. Document quality types
(POOR_QUALITY_DOCUMENT, WRONG_DOCUMENT_TYPE, INCOMPLETE_DOCUMENT,
UNREADABLE_DOCUMENT, DOCUMENT_VERIFICATION_FAILED) indicate specific
issues with uploaded documents. Fraud types (SUSPECTED_FRAUD_DOCUMENT)
indicate suspected fraudulent documents. APPLICANT_* types indicate issues
with the applicant themselves (sanctions, fraud, criminal records, general
rejection).
```
How can I resolve this? If you propose a fix, please make it concise.| description: >- | ||
| Type of verification error. The category-specific MISSING_*_DOCUMENT | ||
| types indicate which document category is needed and determine the | ||
| accepted document types returned in acceptedDocumentTypes. | ||
| Type of verification error. The category-specific MISSING_*_DOCUMENT types | ||
| indicate which document category is needed. Document quality types | ||
| (POOR_QUALITY_DOCUMENT, SUSPECTED_FRAUD_DOCUMENT, etc.) indicate specific | ||
| issues with uploaded documents. APPLICANT_* types indicate issues with the | ||
| applicant themselves (sanctions, fraud, criminal records). |
There was a problem hiding this comment.
APPLICANT_REJECTED undescribed in description
The description's parenthetical for APPLICANT_* types lists "(sanctions, fraud, criminal records)" but omits APPLICANT_REJECTED. It's unclear from the description alone whether APPLICANT_REJECTED is a catch-all for when no more specific APPLICANT_* reason applies, or if it serves a distinct purpose. API consumers won't know when to expect this value vs the more specific types. Adding a brief note (e.g., "or general rejection") would remove the ambiguity.
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/verifications/VerificationErrorType.yaml
Line: 24-29
Comment:
**`APPLICANT_REJECTED` undescribed in description**
The description's parenthetical for `APPLICANT_*` types lists "(sanctions, fraud, criminal records)" but omits `APPLICANT_REJECTED`. It's unclear from the description alone whether `APPLICANT_REJECTED` is a catch-all for when no more specific `APPLICANT_*` reason applies, or if it serves a distinct purpose. API consumers won't know when to expect this value vs the more specific types. Adding a brief note (e.g., "or general rejection") would remove the ambiguity.
How can I resolve this? If you propose a fix, please make it concise.
Merge activity
|
wuvictor-95
deleted the
03-31-update_verificationerrortype_and_verificationstatus
branch
2 participants
No description provided.