zoe/ttx-project-doc
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: defer shopee retcode mapping

Browse Source
This commit is contained in:
曾志威
2026-06-04 15:55:16 +08:00
parent 9792a99db2
commit d27c557f91
1 changed files with 15 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files
superpowers/plans/2026-06-04-shopee-outbound-api-wes-mapping.md
+15 -15
View File
@@ -635,7 +635,7 @@ Convert WES `ResponseMessage` back to Shopee response shape:
[retcode: 0, message: 'success', data: rsp.data ?: [:]] [retcode: 0, message: 'success', data: rsp.data ?: [:]]
``` ```
On WES business error, map to the configured Shopee error code and message. Do not expose WES stack traces. On WES business error, do not implement final Shopee `retcode` mapping yet. Return a generic Shopee failure shape, keep the WES message sanitized, and log the original WES error for later mapping design. Do not expose WES stack traces.
- [ ] **Step 4: Add outbound call method** - [ ] **Step 4: Add outbound call method**
@@ -889,8 +889,9 @@ POST /api/v2/automation/tovendor/inventory/racktransfer/create_rt_order
Failure handling: Failure handling:
- For retryable Shopee errors `-10013099` or timeout, record process history and let existing retry infrastructure retry the sync. - Preserve Shopee `retcode` and message in the EDI call log.
- For non-retryable errors `-10013001`, `-10013023`, `-10013049`, `-10013098`, record the response and block/flag the transfer order according to the current WES transfer failure pattern. - Do not finalize retry/non-retry mapping in this phase.
- Use existing transport failure handling for timeout/network errors only.
- [ ] **Step 5: Add 5.1 and 5.5 Vendor-to-WES basic handlers** - [ ] **Step 5: Add 5.1 and 5.5 Vendor-to-WES basic handlers**
@@ -1002,34 +1003,33 @@ cd C:\work\gitlab\shopee\wes-loghub
.\gradlew :wms-api:compileGroovy :wms-wave:compileGroovy --no-problems-report .\gradlew :wms-api:compileGroovy :wms-wave:compileGroovy --no-problems-report
``` ```
### Task 10: Error Code and Response Contract ### Task 10: Error Code and Response Contract Placeholder
**Files:** **Files:**
- Modify: `ShopeeInboundApiHandler.groovy` - Modify: `ShopeeInboundApiHandler.groovy`
- Modify: `ShopeeOutboundShipmentMappingService.groovy` - Modify: `ShopeeOutboundShipmentMappingService.groovy`
- [ ] **Step 1: Normalize WES response** - [ ] **Step 1: Keep retcode mapping as a placeholder**
WES standard `ResponseMessage` is acceptable inside current sync API. If raw Shopee response shape is required later, add one adapter at the boundary only: WES standard `ResponseMessage` is acceptable inside current sync API. Final mapping from WES errors to Shopee protocol `retcode` is not decided yet and must not be implemented in this phase.
Boundary adapter behavior for now:
```groovy ```groovy
[ [
retcode: rsp.hasError() ? mappedCode : 0, retcode: rsp.hasError() ? -1 : 0,
message: rsp.hasError() ? translatedText : 'success', message: rsp.hasError() ? sanitize(rsp.message) : 'success',
data: rsp.data ?: [:] data: rsp.data ?: [:]
] ]
``` ```
Do not change `ResponseMessage` globally. Keep original WES error code/message in logs for later retcode mapping. Do not change `ResponseMessage` globally.
- [ ] **Step 2: Map retry behavior** - [ ] **Step 2: Defer retry mapping**
Use the protocol: Do not create a retry table or classify business `retcode` values yet.
- Parameter/business errors -> no auto retry. Only transport-level failures such as timeout, connection refused, and upstream unavailable use existing retry behavior. Business retcode retry rules stay pending until the final error-code mapping is confirmed.
- System, DB, timeout, upstream unavailable -> auto retry.
Represent this either as mapped retcode or process-history reason. Do not invent a new retry table unless current sync-fail infrastructure cannot express it.
### Task 11: Verification and Documentation ### Task 11: Verification and Documentation