# WSA Knowledge Base
> Auto-generated. Do not edit manually.
> 🤖 Want AI to read this page? Point it to [`/knowledge-base.md`](/knowledge-base.md)
>
> 📦 [Source](https://code.amazon.com/packages/WarrantyServicesDocumentation)
## Table of Contents
1. [Customer Issues](#1-customer-issues)
1. [SOP: Astro Dormant Warranty Revival](#11-sop-astro-dormant-warranty-revival)
2. [SOP: Bundled Device Warranty Issues](#12-sop-bundled-device-warranty-issues)
3. [SOP: Certified Refurbished Device Warranty Issues](#13-sop-certified-refurbished-device-warranty-issues)
4. [SOP: Claim Resolution Issues](#14-sop-claim-resolution-issues)
5. [SOP: Extended Warranty Missing or Invalid State](#15-sop-extended-warranty-missing-or-invalid-state)
6. [SOP: G2S2 Extended Warranty Configuration Fallback](#16-sop-g2s2-extended-warranty-configuration-fallback)
7. [SOP: Inactive Binding on Expired Warranty](#17-sop-inactive-binding-on-expired-warranty)
8. [SOP: KDSS Order Identification Issues](#18-sop-kdss-order-identification-issues)
9. [SOP: No Replacement Options Error](#19-sop-no-replacement-options-error)
10. [SOP: OBA Order Binding Issues](#110-sop-oba-order-binding-issues)
11. [SOP: Order-Level Replacement and Refund Block Issues](#111-sop-order-level-replacement-and-refund-block-issues)
12. [SOP: Order Reassignment Issues](#112-sop-order-reassignment-issues)
13. [SOP: Privacy Compliance DLQ Issues](#113-sop-privacy-compliance-dlq-issues)
14. [SOP: Unable to Determine Original ASIN](#114-sop-unable-to-determine-original-asin)
15. [SOP: Warranty Binding Issues](#115-sop-warranty-binding-issues)
16. [SOP: Warranty Deletion Issues (Old Devices)](#116-sop-warranty-deletion-issues-old-devices)
17. [SOP: Warranty Type & Configuration Mismatches](#117-sop-warranty-type--configuration-mismatches)
18. [SOP: WSA Self Replacement Null Fields](#118-sop-wsa-self-replacement-null-fields)
2. [Alarms](#2-alarms)
1. [SOP: 5XX TransferLW for CanceledClaim Alarm](#21-sop-5xx-transferlw-for-canceledclaim-alarm)
2. [SOP: DynamoDB High TPS Alarm Analysis](#22-sop-dynamodb-high-tps-alarm-analysis)
3. [SOP: Missing Marketplace Configuration Alarm](#23-sop-missing-marketplace-configuration-alarm)
3. [Human-Only Documentation](#3-human-only-documentation)
1. [Andes Table Data Quality Issues](#31-andes-table-data-quality-issues)
2. [Edge Cases (Manual Fixes)](#32-edge-cases-manual-fixes)
3. [G2S2 & RMP Configuration](#33-g2s2--rmp-configuration)
4. [Infrastructure Emergencies](#34-infrastructure-emergencies)
5. [Oncall Reference](#35-oncall-reference)
6. [Pipeline & Deployment](#36-pipeline--deployment)
7. [Privacy Compliance (Boomerang / AEDU / SandFire)](#37-privacy-compliance-boomerang--aedu--sandfire)
---
## 1. Customer Issues
### 1.1. SOP: Astro Dormant Warranty Revival
#### Applicability
**Use this SOP when:**
- Ticket mentions Astro device warranty issues
- Warranty lookup shows "Dormant Warranty" indicator
- Customer cannot use warranty coverage on Astro device
**DO NOT use if:**
- Issue is about "Astro Workflow" (different system)
- Device is not an Astro device
- Warranty is not in dormant state
#### Prerequisites
- Device serial number (DSN) from ticket
- Device type (commonly: `A2MDL5WTJIU8SZ` for Astro)
---
#### Procedure
##### Step 1: Verify Dormant Warranty Status
First, use the API operation to get the CS view of warranties:
```json
{
"operation": "GET_WARRANTIES_BY_DEVICE",
"params": { "dsn": "" }
}
```
Note: deviceType is auto-looked up from DIS if not provided.
**Expected:** Response may show warranty issues or missing warranty
**If warranty shows normally:** This SOP may not apply.
---
##### Step 2: Query DormantWarranty Table
Use the direct operation to check for dormant warranties:
```json
{
"operation": "QUERY_DORMANT_WARRANTIES",
"params": { "dsn": "" }
}
```
Note: deviceType is auto-looked up from DIS if not provided.
**Expected:** Returns dormant warranty record with `warrantyId`
---
##### Step 3: Get Event History (Optional)
If you need to understand what happened to the warranty:
```json
{
"operation": "QUERY_EVENT_SOURCE",
"params": { "warrantyId": "" }
}
```
This shows the full audit trail of warranty events.
---
##### Step 4: Extract Required Information
From query results:
- `warrantyId` - Format: `Warranty-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX` or `Warranty-NUMERIC`
Determine dates:
- `startDate` - When warranty should begin (YYYY-MM-DD)
- `expirationDate` - When warranty should expire (YYYY-MM-DD)
- Standard limited warranty: 1 year from device activation/purchase
---
##### Step 5: Escalate for Manual Revival
**REVIVE_DORMANT_WARRANTY requires human engineer execution.**
Provide this payload for manual execution:
```json
{
"OPERATION": "REVIVE_DORMANT_WARRANTY",
"warrantyId": "",
"startDate": "",
"expirationDate": ""
}
```
Engineer executes via OncallOperationsUtilityContainerLambda.
---
##### Step 6: Verification (Post-Revival)
Use the API operation to verify the warranty is now active:
```json
{
"operation": "GET_WARRANTIES_BY_DEVICE",
"params": { "dsn": "" }
}
```
**Verify:**
- Warranty shows as active LIMITED_WARRANTY (not dormant)
- Correct `startDate` and `expirationDate`
- `customerId` is associated
---
#### Stop Conditions
Escalate if:
- Device is not Astro type
- No dormant warranty record found
- Cannot determine appropriate dates
- Any tool error
---
#### Example
**Ticket:** V2056018398 - Astro device warranty not working
**Resolution:**
1. Queried device - confirmed dormant indicator
2. Found Warranty-abc123-def456 in DormantWarranties table
3. Prepared revival payload, escalated for manual execution
4. Engineer executed, verification confirmed active warranty
---
#### Region Reference
| Marketplace | Region |
|-------------|--------|
| NA | us-east-1 |
| EU | eu-west-1 |
| FE | us-west-2 |
---
### 1.2. SOP: Bundled Device Warranty Issues
#### Applicability
**Use this SOP when:**
- Issue involves Fire TV Stick/Cube with accessory remote
- Issue involves Echo Buds (Puget/Powell) with multiple components
- Warranty missing for a bundled component
- EW not binding to replacement bundled device
**DO NOT use if:**
- Device is not a bundled device (single-component device)
- Issue is about replacement options availability (use no-replacement-options SOP)
- Issue is about EW binding to wrong device (use warranty-binding SOP)
#### Prerequisites
- Device serial number (DSN) of the base device
- Component information (which part needs replacement)
---
#### Key Concept: Bundled Devices
Bundled devices (e.g., Fire TV + Remote) share a single Limited Warranty bound to the base device DSN. Claims can be made against this single warranty to replace either the base device or the accessory. Only the base device has a DSN bound to the warranty.
---
#### Issue Type 1: Missing Warranty on Bundled Base Unit
##### When to Use
- Base device has no warranty
- KDSS fulfillment may have been missed for the bundle
##### Procedure
**Step 1: Check Warranty State**
```json
{
"operation": "GET_WARRANTIES_BY_DEVICE",
"params": { "dsn": "" }
}
```
**Step 2: Attempt Backfill**
```json
{
"operation": "BACKFILL_LIMITED_WARRANTY",
"params": { "dsn": "" }
}
```
**Step 3: If Backfill Fails — Check Shipments**
```json
{
"operation": "GET_DEVICE_SHIPMENTS",
"params": { "dsn": "" }
}
```
If shipment data exists but KDSS didn't fulfill, escalate to oncall engineer to construct and send a KDSS SQS payload (see kdss-order-identification SOP advanced path).
If no shipment data exists, reassign to KDSS: Digital Media Technology > Kindle Device Sales > KindleDeviceSalesService.
---
#### Issue Type 2: EW Not Bound to Replacement Bundled Device
##### When to Use
- Claim was made on bundled device, replacement has different Device Type
- EW stayed on old device, didn't transfer to replacement
- Replacement Device Type may not be registered as a Bundled Base Unit in WSA
##### Procedure
**Step 1: Verify Both Devices**
```json
{
"operation": "GET_WARRANTIES_BY_DEVICE",
"params": { "dsn": "" }
}
```
```json
{
"operation": "GET_WARRANTIES_BY_DEVICE",
"params": { "dsn": "" }
}
```
Confirm EW is still bound to old device.
**Step 2: Invalidate Old Binding**
```json
{
"operation": "INVALIDATE_BINDING",
"params": {
"warrantyId": "",
"bindingId": ""
}
}
```
**Step 3: Bind to New Device**
```json
{
"operation": "BIND_EXTENDED_WARRANTY",
"params": {
"warrantyId": "",
"dsn": "",
"deviceType": "",
"orderId": "",
"orderItemId": "",
"orderLineItemId": "",
"orderUnitId": "",
"marketplaceId": ""
}
}
```
**Step 4: Verify**
```json
{
"operation": "GET_WARRANTIES_BY_DEVICE",
"params": { "dsn": "" }
}
```
---
#### Issue Type 3: Claim on Base Unit with Stuck Previous Claim (KWS Data)
##### When to Use
- Old KWS claim from before WSA launch is stuck
- Second fulfillment of bundled device failed due to KDSS propagation delay
- Error: "Check if this device has already been replaced by a different device"
##### Procedure
**Step 1: Check Event History**
```json
{
"operation": "QUERY_EVENT_SOURCE",
"params": { "warrantyId": "" }
}
```
Look for a stuck `CreateLimitedWarrantyForDeviceShipment` operation.
**Step 2: Escalate to Oncall**
Provide the oncall engineer with:
- The original CreateLW request data from Event Source
- The KDSS SQS payload format needed to re-trigger fulfillment
Oncall must send the corrected KDSS payload to the `KDSSFulfillmentEventsQueue`.
---
#### Issue Type 4: Echo Buds Multi-Component EW Replacement
##### When to Use
- Echo Buds (Puget/Powell) — all components need replacement
- EW can only have one binding, but device has 3 components
##### Procedure
This is an edge case WSA software doesn't handle correctly. An EW can only bind to one component replacement at a time.
**Resolution:** Escalate to oncall engineer. The fix is to extend the limited warranty coverage for the excess components that need replacing. Long-term fix tracked in WSA-1756.
---
#### Stop Conditions
Escalate if:
- Replacement Device Type is not registered as a Bundled Base Unit in WSA config (requires code change)
- Multiple claims are stuck on the same warranty
- Echo Buds multi-component scenario (always escalate)
---
### 1.3. SOP: Certified Refurbished Device Warranty Issues
#### Applicability
**Use this SOP when:**
- Customer purchased certified refurbished device
- System shows expired warranty from previous owner
- Customer offered OOW discount instead of coverage
- Warranty shows wrong customer ID
**DO NOT use if:**
- Device is new (not refurbished)
- Warranty already belongs to current customer
---
#### GDPR Compliance Requirement
Each customer MUST have their own warranty record.
**Correct workflow:**
1. ✅ Invalidate old warranty (from original owner)
2. ✅ Backfill new warranty (for new customer)
3. ✅ Verify dates (adjust only if FRO sets them wrong)
**❌ NEVER just use `setWarrantyDates` on existing warranty** - violates GDPR
---
#### Procedure
##### Step 1: Verify Current State
**Tool:** `DynamoDBQueryTool.queryByDeviceSerial`
```json
{ "deviceSerialNumber": "" }
```
Identify:
- Current warranty ID
- Current customer ID (previous owner)
- Current dates (expired)
- New customer ID (from ticket)
---
##### Step 2: Invalidate Old Warranty
**Tool:** `WSAOncallOperationsTool.invalidateWarranty`
```json
{ "warrantyId": "" }
```
---
##### Step 3: Backfill New Warranty
**Tool:** `WSAOncallOperationsTool.backfillLimitedWarranty`
```json
{
"deviceSerialNumber": "",
"deviceType": "",
"customerId": ""
}
```
FRO will automatically set dates based on device activation.
---
##### Step 4: Verify New Warranty
**Tool:** `DynamoDBQueryTool.queryByDeviceSerial`
Verify:
- New warranty ID exists (different from old)
- Customer ID matches NEW customer
- Start date around purchase/activation
- Expiration = start + 1 year
---
##### Step 5: Adjust Dates (Only If Needed)
**Only if FRO set incorrect dates:**
**Tool:** `WSAOncallOperationsTool.setWarrantyDates`
```json
{
"warrantyId": "",
"startDate": "",
"endDate": ""
}
```
---
#### Example
**Ticket:** D377090790
**Issue:** Customer purchased refurbished Fire Tablet Oct 28, 2025. System showed expired warranty from previous owner.
**Resolution:**
1. Invalidated old warranty (Warranty-092f26d0...)
2. Backfilled new warranty for new customer
3. Verified FRO dates were correct (Oct 30, 2025 - Nov 2, 2026)
4. No date adjustment needed
---
#### Stop Conditions
Escalate if:
- Cannot identify new customer ID
- Device type unclear
- Invalidate or backfill fails
- Multiple active warranties after backfill
---
### 1.4. SOP: Claim Resolution Issues
#### Applicability
**Use this SOP when:**
- Claim was incorrectly canceled and needs to be un-canceled
- Customer received empty box, needs new claim
- Replacement device was fulfilled to wrong customer
- Shipment failed/undeliverable, warranty stuck in "Waiting for replacement"
**DO NOT use if:**
- Issue is about warranty binding (use warranty-binding SOP)
- Issue is about missing warranty (use kdss-order-identification SOP)
- Customer wants to transfer warranty back after keeping original device (use warranty-binding Type 4)
#### Prerequisites
- Device serial number (DSN)
- Warranty ID or Claim ID (if available)
---
#### Issue Type 1: Un-cancel Claim (Mistaken Cancellation)
##### When to Use
- CSA accidentally canceled a claim
- Warranty reverted to previous device but should be on replacement
- Need to undo the cancellation event
##### Procedure
**Step 1: Get Warranty and Claim Details**
```json
{
"operation": "GET_WARRANTIES_BY_DEVICE",
"params": { "dsn": "" }
}
```
**Step 2: Find the Cancel Transaction**
```json
{
"operation": "QUERY_EVENT_SOURCE",
"params": { "warrantyId": "" }
}
```
Find the transaction ID associated with the canceled claim event.
**Step 3: Escalate for Rollback**
ROLLBACK_TRANSACTION is a blocked operation. Provide the oncall engineer with:
- Warranty ID
- Transaction ID of the cancel event
- Explanation of why the cancel was incorrect
**Oncall engineer** must use WSA Tools Oncall Operations > Rollback Transaction with the transaction ID. This deletes the cancel events from Event Source, restoring the warranty to the replacement device.
**Step 4: Verify**
```json
{
"operation": "GET_WARRANTIES_BY_DEVICE",
"params": { "dsn": "" }
}
```
Confirm warranty is now bound to the replacement device.
---
#### Issue Type 2: Empty Box / DRPS No Claim Codes
##### When to Use
- Customer received empty replacement box (missing device)
- CSA tries to issue another replacement, gets "DRPS didn't return any ClaimCodes"
- Previous claim is blocking new claim
##### Procedure
**Step 1: Get Current State**
```json
{
"operation": "GET_WARRANTIES_BY_DEVICE",
"params": { "dsn": "" }
}
```
Identify the active claim that is blocking.
**Step 2: Cancel the Blocking Claim**
```json
{
"operation": "CANCEL_CLAIM",
"params": { "claimId": "" }
}
```
**Step 3: Verify**
```json
{
"operation": "GET_WARRANTIES_BY_DEVICE",
"params": { "dsn": "" }
}
```
Confirm warranty is back on the original device and claim codes are now available. Direct CSA to issue a new claim.
---
#### Issue Type 3: Replacement Fulfilled to Another Customer
##### When to Use
- Customer sent replacement device back to Amazon by mistake
- Amazon re-sold the replacement to a different customer
- Original customer's warranty was invalidated when new customer's warranty was created
##### Procedure
**Step 1: Check Event History**
```json
{
"operation": "QUERY_EVENT_SOURCE",
"params": { "warrantyId": "" }
}
```
Look for:
- `CreateLimitedWarrantyForDeviceShipment` OperationRequestReceived event (from new customer's fulfillment)
- `BindingInvalidated` event
- `WarrantyInvalidated` event
**Step 2: Escalate for Manual DDB Fix**
This requires deleting events from DynamoDB Event Source (blocked operation). Provide the oncall engineer with:
- Warranty ID
- The specific events to delete (the last 2-3 events: CreateLW request, BindingInvalidated, WarrantyInvalidated)
- Timestamps of the events
**Oncall engineer** must delete these events from Event Source, then verify the warranty is restored. After restoration, cancel the claim using WSA Tools.
---
#### Issue Type 4: Shipment Undeliverable / Failed Shipment
##### When to Use
- Replacement device shipment failed delivery
- Device returned to Amazon warehouse
- Warranty shows "Waiting for replacement order"
- Another claim may have been made, creating a stuck state
##### Procedure
**Step 1: Get Warranty State**
```json
{
"operation": "GET_WARRANTIES_BY_DEVICE",
"params": { "dsn": "" }
}
```
**Step 2: Find the Stuck Claim**
```json
{
"operation": "GET_WARRANTIES_BY_DEVICE",
"params": { "dsn": "" }
}
```
Identify the claim that links the original DSN to the stuck replacement DSN.
**Step 3: Cancel the Stuck Claim**
```json
{
"operation": "CANCEL_CLAIM",
"params": { "claimId": "" }
}
```
This releases the original customer's warranty from the failed shipment.
**Step 4: Verify**
```json
{
"operation": "GET_WARRANTIES_BY_DEVICE",
"params": { "dsn": "" }
}
```
Confirm warranty is no longer stuck and customer can proceed with a new replacement.
---
#### Stop Conditions
Escalate if:
- ROLLBACK_TRANSACTION needed (always escalate — blocked operation)
- Manual DDB event deletion needed (always escalate)
- Multiple claims are interleaved on the same warranty
- Replacement device is now owned by a different customer with an active warranty
---
### 1.5. SOP: Extended Warranty Missing or Invalid State
#### Applicability
**Use this SOP when:**
- Customer purchased an extended warranty but it does not exist in WSA
- Extended warranty shows as "refunded" when it was never refunded
- Error: "No extended warranty found for order"
**DO NOT use if:**
- EW exists but won't bind to device (use warranty-binding SOP)
- EW config is missing for an ASIN (use g2s2-config-fallback SOP)
- Issue is about limited warranty (use kdss-order-identification SOP)
#### Prerequisites
- Customer ID or Order ID for the EW purchase
- Ticket creation timestamp
---
#### Issue Type 1: Extended Warranty Never Created (Missed BuyNewEW)
##### When to Use
- Customer purchased EW but no EW record exists in WSA
- Order shows EW purchase but WSA has no corresponding warranty
##### Procedure
**Step 1: Search for EW by Order**
```json
{
"operation": "GET_EXTENDED_WARRANTIES_BY_ORDER",
"params": { "orderId": "" }
}
```
**Expected:** Empty result or no matching EW.
**Step 2: Search for EW by Customer**
```json
{
"operation": "GET_EXTENDED_WARRANTIES_BY_CUSTOMER",
"params": { "customerId": "" }
}
```
Confirm no EW exists for this purchase.
**Step 3: Escalate for Manual EW Creation**
CREATE_EW is a blocked operation. Provide the oncall engineer with:
- Order ID
- Customer ID
- EW ASIN (from the order/ticket)
- Marketplace ID
- Order date (epoch seconds — use order date, NOT epoch milliseconds)
**Oncall engineer** must use the OncallOperationsLambda `CREATE_EW` operation or manually hit the BuyNewExtendedWarranty API Gateway endpoint with the order data from Grass.
**Step 4: Verify**
```json
{
"operation": "GET_EXTENDED_WARRANTIES_BY_ORDER",
"params": { "orderId": "" }
}
```
Confirm EW now exists.
---
#### Issue Type 2: Extended Warranty Incorrectly Refunded
##### When to Use
- EW exists but shows as refunded
- Customer never requested a refund
- Device cannot be replaced because EW is marked refunded
##### Procedure
**Step 1: Verify EW State**
```json
{
"operation": "GET_EXTENDED_WARRANTIES_BY_CUSTOMER",
"params": { "customerId": "" }
}
```
Identify the EW that shows as refunded.
**Step 2: Check Event History**
```json
{
"operation": "QUERY_EVENT_SOURCE",
"params": { "warrantyId": "" }
}
```
Look for a refund event. Verify whether it was legitimate.
**Step 3: Escalate for Manual Fix**
Reactivating a refunded EW requires direct DynamoDB Event Source edits (not available to the agent). Provide the oncall engineer with:
- Warranty ID
- The refund event details from Event Source
- Confirmation that the refund was not legitimate (cross-reference with Grass order data)
**Oncall engineer** must go into the DDB Event Source table and re-activate the EW by editing the refund event.
---
#### Stop Conditions
Escalate if:
- Order data cannot be found
- Multiple EWs are affected for the same customer
- Refund appears legitimate after checking Grass
---
### 1.6. SOP: G2S2 Extended Warranty Configuration Fallback
#### Applicability
**Use this SOP when:**
- Ticket mentions G2S2EWConfigGlobalDefaultFallback error
- Extended warranty purchase fails with configuration error
- System falls back to global default configuration
**DO NOT use if:**
- Issue is about limited warranty (not extended warranty)
- Error is not related to G2S2 configuration
#### Prerequisites
- Ticket creation timestamp
- Marketplace ID (to determine AWS region)
- ASIN from the error
---
#### Procedure
##### Step 1: Search CloudWatch for Error
**Tool:** `CloudWatchLogsTool.searchLogs`
```json
{
"logGroup": "WSAMainLogs",
"query": "fields @timestamp, @message | filter @message like 'G2S2EWConfigGlobalDefaultFallback' | sort @timestamp desc",
"startTime": "",
"endTime": ""
}
```
**Expected:** Log entries showing the fallback metric
---
##### Step 2: Extract Request Details
From logs, identify:
- AWS Request ID
- Order ID
- ASIN
- Marketplace ID
- Customer ID
---
##### Step 3: Get Full Request Logs
**Tool:** `CloudWatchLogsTool.searchLogs`
```json
{
"logGroup": "WSAMainLogs",
"query": "fields @timestamp, @message | filter @message like '' | sort @timestamp asc"
}
```
---
##### Step 4: Identify Root Cause
The G2S2EWConfigGlobalDefaultFallback indicates:
- Missing extended warranty configuration for the ASIN
- System used global default instead of ASIN-specific config
- Configuration needed in G2S2 `klaw_kws_extend_warranty_configs` table
---
##### Step 5: Resolution
**Escalate to Extended Warranty Onboarding POC:**
- Contact: kulsonam@
- Provide: ASIN, Marketplace ID, Order ID
- Request: Add proper configuration in G2S2
---
---
#### Additional Scenario: EW Config Missing Covered Device ASIN
##### When to Use
- Error: "Cannot bind product to warranty due to no replaceable bindings found"
- EW ASIN does not cover the device ASIN in G2S2 config
- Common in JP marketplace
##### Procedure
**Step 1: Get Device ASIN**
```json
{
"operation": "QUERY_KEY_TABLE_BY_DEVICE",
"params": { "dsn": "" }
}
```
Note the ASIN from the warranty data.
**Step 2: Check EW ASINs for Device**
```json
{
"operation": "GET_EW_ASINS",
"params": { "dsn": "" }
}
```
If the EW ASIN is not in the list of valid EW ASINs for this device, the G2S2 config is missing the mapping.
**Step 3: Escalate for G2S2 Config Update**
Contact the EW Onboarding POC (kulsonam@) and provide:
- Device ASIN
- EW ASIN
- Marketplace ID
- Device Type
The fix requires uploading a CSV to the `warranty-configuration-lambda-bucket-prod` S3 bucket with the correct ASIN mapping, then running `UpdateWarrantyConfig` via the oncall lambda for the affected warranty.
---
#### Stop Conditions
Escalate if:
- Cannot find error in CloudWatch logs
- Multiple ASINs affected (may indicate broader issue)
- Configuration already exists but still failing
---
#### Region Reference
| Marketplace | Region |
|-------------|--------|
| NA | us-east-1 |
| EU | eu-west-1 |
| FE | us-west-2 |
---
### 1.7. SOP: Inactive Binding on Expired Warranty
#### Applicability
**Use this SOP when:**
- Error: "There is no actively bound limited warranty to the product"
- Customer has active Extended Warranty (EW)
- Limited Warranty (LW) exists but has inactive binding
**DO NOT use if:**
- No warranty exists at all
- Issue is about warranty expiration (not binding)
#### Prerequisites
- Device serial number (DSN)
- Device type
---
#### Procedure
##### Step 1: Get Warranty Information
**Tool:** `WarrantyServicesTool.getWarrantiesByDevice`
```json
{
"deviceSerialNumber": "",
"includeClaims": true,
"includeUnboundEW": true,
"includePreviouslyBoundWarranties": true
}
```
**Look for:**
- Active Extended Warranty
- Expired Limited Warranty with inactive binding
---
##### Step 2: Check Binding Status in DynamoDB
**Tool:** `DynamoDBQueryTool.queryKeyTable`
```json
{
"warrantyId": "",
"projection": "warrantyData"
}
```
**Check bindings array:**
- `isActive: false` = INACTIVE binding (causes the error)
- `isActive: true` = ACTIVE binding (should work)
---
##### Step 3: Backfill New Limited Warranty
**Tool:** `WarrantyServicesTool.backfillLimitedWarranty`
```json
{
"deviceSerialNumber": "",
"deviceType": ""
}
```
This creates:
- New LIMITED_WARRANTY with active binding
- Enables GetReplacementOptions to work
---
##### Step 4: Verify Fix
**Tool:** `WarrantyServicesTool.getWarrantiesByDevice`
```json
{
"deviceSerialNumber": "",
"includeClaims": true
}
```
**Verify:**
- New warranty exists with active binding
- Replacement options now available
---
#### Key Concepts
**Warranty Validity vs Binding Activity:**
- `warrantyInvalid: false` = warranty is VALID (can be expired but valid)
- `isActive: true` on binding = binding is ACTIVE
**Default Customer ID:**
- `A23ZP02F085DFQ` = system placeholder, NOT a conflict
---
#### Stop Conditions
Escalate if:
- Backfill fails
- Multiple conflicting warranties exist
- Issue persists after backfill
---
#### Region Reference
| Marketplace | Region |
|-------------|--------|
| NA | us-east-1 |
| EU | eu-west-1 |
| FE | us-west-2 |
---
### 1.8. SOP: KDSS Order Identification Issues
#### Applicability
**Use this SOP when:**
- Error: "Exception calling WSA.BackfillLimitedWarrantyV2 for request"
- Error: "KDSS cannot identify an order for deviceSerialNumber"
- Warranty lookup returns empty list
**DO NOT use if:**
- Warranty exists but has other issues
- Error message is different
#### Prerequisites
- Device serial number (DSN)
- Device type
- Ticket creation timestamp
---
#### Procedure
##### Step 1: Verify Empty Warranty List
**Tool:** `WarrantyServicesTool.getWarrantiesByDevice`
```json
{
"deviceSerialNumber": "",
"includeClaims": true
}
```
**Expected:** Empty warranty list `{ "warrantyList": [] }`
---
##### Step 2: Confirm KDSS Error
**Tool:** `WarrantyServicesTool.getWarrantyClaimCode`
```json
{
"deviceSerialNumber": ""
}
```
**Expected:** Exception with "KDSS cannot identify an order" message
---
##### Step 3: Search CloudWatch for Confirmation
**Tool:** `CloudWatchLogsTool.searchLogs`
```json
{
"logGroup": "WSAMainLogs",
"query": "fields @timestamp, @message | filter @message like 'KDSS cannot identify an order for deviceSerialNumber: []' | sort @timestamp desc",
"startTime": "",
"endTime": ""
}
```
---
##### Step 4: Reassign to KDSS Team
**CTI Path:** Digital Media Technology > Kindle Device Sales > KindleDeviceSalesService
**Include in reassignment:**
- Device Serial Number
- Device Type
- CloudWatch error message
- Request: Fulfill device in KDSS system
---
#### Resolution
Once KDSS fulfills the device:
- System automatically creates warranty
- No further WSA action needed
---
#### Advanced: Manual KDSS Fulfillment (If KDSS Cannot Fulfill)
If KDSS cannot fulfill the device through normal channels, an oncall engineer can manually construct and send a KDSS payload:
**Step 1: Get Device Shipments**
```json
{
"operation": "GET_DEVICE_SHIPMENTS",
"params": { "dsn": "" }
}
```
This returns shipment info which usually contains test order data that KDSS did not persist as a real order.
**Step 2: Construct KDSS Payload**
Using the shipment data, the oncall engineer constructs a payload for the `KDSSFulfillmentEventsQueue`:
```json
{
"KDSSPayload": {
"deviceSerialNumber": "",
"deviceType": "",
"orderId": "",
"orderItemId": "",
"orderLineItemId": "",
"orderUnitId": "",
"orderInstance": 0,
"marketplaceId": "",
"warrantyId": "",
"customerId": "",
"asin": ""
}
}
```
**Step 3: Send and Verify**
Oncall engineer sends the payload to the SQS queue in the WSA AWS account. Wait 1-2 minutes, then verify:
```json
{
"operation": "GET_WARRANTIES_BY_DEVICE",
"params": { "dsn": "" }
}
```
A limited warranty should now appear.
---
#### Stop Conditions
Escalate if:
- Error message is different than expected
- KDSS reports device already fulfilled
- Issue persists after KDSS action
---
#### Region Reference
| Marketplace | Region |
|-------------|--------|
| NA | us-east-1 |
| EU | eu-west-1 |
| FE | us-west-2 |
---
### 1.9. SOP: No Replacement Options Error
#### Applicability
**Use this SOP when:**
- Error: "No replacement options were returned"
- Customer service cannot create device replacement
- Warranty exists and is valid
**DO NOT use if:**
- No warranty exists (use KDSS SOP)
- Warranty is expired or invalid
#### Prerequisites
- Device serial number (DSN)
- Ticket creation timestamp
---
#### Procedure
##### Step 1: Search CloudWatch for Request
**Tool:** `CloudWatchLogsTool.searchLogs`
```json
{
"logGroup": "WSAMainLogs",
"query": "fields @timestamp, @message | filter @message like 'WSA Request: [GetReplacementOptionsRequest' and @message like '' | sort @timestamp desc",
"startTime": "",
"endTime": ""
}
```
Extract the Request ID from results.
---
##### Step 2: Find Filter Logs
**Tool:** `CloudWatchLogsTool.searchLogs`
```json
{
"logGroup": "WSAMainLogs",
"query": "fields @timestamp, @message | filter @message like '' and @message like 'ReplacementOptions Filter' | sort @timestamp asc"
}
```
---
##### Step 3: Analyze Filter Reasons
**Common filter reasons:**
- `AvailabilityFilter`: quantity < 5 (hard-coded threshold)
- `AvailabilityFilter`: quantity = 0
- `PreorderableFilter`: item is preorderable
---
##### Step 4: Reassign to KRIS Team
**CTI Path:** Digital Media Technology > Kindle Reverse Logistics Tech > Kindle Replacement Info Service
**Include in reassignment:**
- Device Serial Number
- Filter reasons from logs
- ASINs that were filtered out
- Request: Update inventory/availability
---
#### Root Cause
WSA filters out replacement options when:
- Inventory quantity < 5 (hard-coded rule)
- Item has zero quantity
- Item is preorderable
This is a KRIS inventory issue, not a WSA issue.
---
#### Additional Scenario: Missing Bundled Component Replacement Option
##### When to Use
- CSA cannot select an accessory/bundled component for replacement
- Component (e.g., remote for Fire TV) is missing from the replacement options list
- Base device replacement options work fine
##### Root Cause
WSA retrieves bundled components from KRIS. If KRIS is missing an accessory in the bundled components configuration, CSAs will not see it as a replaceable component.
##### Resolution
Reassign to KRIS with the Device Type and ASIN, stating which bundled components are missing.
**CTI Path:** Digital Media Technology > Kindle Reverse Logistics Tech > Kindle Replacement Info Service
---
#### Stop Conditions
Escalate if:
- No filter logs found
- Issue is not inventory-related
- KRIS reports inventory is correct
---
#### Region Reference
| Marketplace | Region |
|-------------|--------|
| NA | us-east-1 |
| EU | eu-west-1 |
| FE | us-west-2 |
---
### 1.10. SOP: OBA Order Binding Issues
#### Applicability
**Use this SOP when:**
- Error: "Unable to determine original asin so replacement options cannot be provided"
- Device is bound to OBA (factory test) order
- Order ID starts with "OBA-"
**DO NOT use if:**
- Error is due to null ASIN in events (use unable-to-determine-original-asin SOP)
- No warranty exists (use KDSS SOP)
#### Prerequisites
- Device serial number (DSN)
- Device type
---
#### Procedure
##### Step 1: Get Warranty Information
**Tool:** `WarrantyServicesTool.getWarrantiesByDevice`
```json
{
"deviceSerialNumber": "",
"includeClaims": true
}
```
Extract the LIMITED_WARRANTY_ID.
---
##### Step 2: Check Order ID in DynamoDB
**Tool:** `DynamoDBQueryTool.queryKeyTable`
```json
{
"warrantyId": "",
"projection": "warrantyData"
}
```
**Look for OBA order:**
```json
"coveredProduct": {
"coveredProductEntityReferences": [{
"@type": "AmazonDeviceOrder",
"orderId": "OBA-12345678" // ← OBA prefix = factory test order
}]
}
```
---
##### Step 3: Try Approach 1 - Update Configuration
**Tool:** `WarrantyServicesTool.updateWarrantyConfiguration`
```json
{
"warrantyId": "",
"fetchAsin": true
}
```
---
##### Step 4: Verify Fix
**Tool:** `DynamoDBQueryTool.queryKeyTable`
```json
{
"warrantyId": "",
"projection": "warrantyData"
}
```
If ASIN is now populated, issue is resolved.
---
##### Step 5: If Approach 1 Fails - Invalidate and Recreate
**Tool:** `WarrantyServicesTool.invalidateWarranty`
```json
{
"warrantyId": ""
}
```
**Then:**
**Tool:** `WarrantyServicesTool.backfillLimitedWarranty`
```json
{
"deviceSerialNumber": "",
"deviceType": ""
}
```
---
##### Step 6: If Still OBA - Reassign to KDSS
**CTI Path:** Digital Media Technology > Kindle Device Sales > KindleDeviceSalesService
**Include:**
- Device Serial Number
- Explanation: Device bound to OBA order
- Request: Fulfill device with proper order
---
#### Stop Conditions
Escalate if:
- Update configuration fails
- Backfill still creates OBA binding
- KDSS reports no valid order exists
---
#### Region Reference
| Marketplace | Region |
|-------------|--------|
| NA | us-east-1 |
| EU | eu-west-1 |
| FE | us-west-2 |
---
### 1.11. SOP: Order-Level Replacement and Refund Block Issues
#### Applicability
**Use this SOP when:**
- CS reports "WSA is blocking" order-level returns/refunds/replacements
- Error mentions "Return window is blocked by warranty service request"
- CS claims warranty is preventing refund
**DO NOT use if:**
- Issue is actually about warranty claims
- Device-level replacement (not order-level)
#### Critical Understanding
**WSA does NOT and CANNOT block order-level operations:**
- WSA has NO influence on order-level replacements
- WSA NEVER blocks refunds
- Order-level operations bypass WSA completely
When CS reports "WSA is blocking" an order-level operation, this is ALWAYS a misdiagnosis.
---
#### Procedure
##### Step 1: Verify Warranty Status
**Tool:** `WarrantyServicesTool.getWarrantiesByDevice`
```json
{
"deviceSerialNumber": "",
"includeClaims": true,
"includeUnboundEW": true,
"includePreviouslyBoundWarranties": true
}
```
Document:
- Warranty IDs
- Claim history (active/cancelled)
- Binding status
- Expiration dates
---
##### Step 2: Provide Warranty Status to CS
**What WSA CAN do:**
- Provide warranty status information
- Unbind warranties (if requested)
- Cancel warranty claims (if needed)
- Provide claim history
**What WSA CANNOT do:**
- Unblock order-level return windows
- Enable refund options
- Override order-level replacement rules
---
##### Step 3: Direct CS to Proper Escalation
**Response to CS:**
```
The warranty information has been reviewed. WSA does not control order-level
return/refund operations. Please escalate to your CS lead or the appropriate
team to resolve the order-level blocking issue.
Warranty Status for Reference:
- Warranty ID: [ID]
- Claim Status: [Active/Cancelled/None]
- [Additional relevant warranty details]
```
---
#### Key Points
- WSA = Warranty management system ONLY
- Order-level operations are handled by OTHER systems
- "Warranty blocking refund" is ALWAYS a misdiagnosis
- CS should escalate to their lead for order-level issues
---
#### Alternative Solutions for CS
1. Manual override of return restrictions
2. Process concession/promotional credit
3. Escalate to appropriate team for system-level investigation
---
#### Stop Conditions
This SOP is informational only. WSA cannot resolve order-level blocking issues.
If CS insists WSA is the cause:
- Provide warranty status documentation
- Reiterate that WSA does not control order-level operations
- Recommend CS escalate to their lead
---
### 1.12. SOP: Order Reassignment Issues
#### Applicability
**Use this SOP when:**
- Device needs to be reassigned to a different order
- Incorrect order association during fulfillment
- Customer service adjustment requires order change
**DO NOT use if:**
- Issue is about warranty status (not order)
- Device has no existing warranty
#### Prerequisites
- Device serial number (DSN)
- Current order ID
- Proposed (correct) order ID
---
#### Procedure
##### Step 1: Check Device Shipments
**Tool:** `WarrantyServicesTool.getDeviceShipments`
```json
{
"deviceSerialNumber": ""
}
```
**Check if proposed order exists in shipments.**
---
##### Step 2A: If Proposed Order EXISTS in Shipments
**Cancel existing warranty:**
**Tool:** `WarrantyServicesTool.invalidateWarranty`
```json
{
"warrantyId": ""
}
```
**Backfill new warranty:**
**Tool:** `WarrantyServicesTool.backfillLimitedWarranty`
```json
{
"deviceSerialNumber": "",
"deviceType": ""
}
```
**Verify new warranty:**
**Tool:** `WarrantyServicesTool.getWarrantiesByDevice`
```json
{
"deviceSerialNumber": "",
"includeClaims": true
}
```
---
##### Step 2B: If Proposed Order DOES NOT EXIST in Shipments
**Reassign ticket to KDSS:**
**CTI Path:** Digital Media Technology > Kindle Device Sales > KindleDeviceSalesService
**Include:**
- Device Serial Number
- Current Order ID
- Proposed Order ID
- Request: Fulfill device with proposed order
Once KDSS completes fulfillment, system automatically creates warranty under new order.
---
#### Important Notes
- Do NOT include sensitive customer information in ticket comments
- Do NOT mention RCH (replacement) orders in comments
- Keep ticket comments concise
---
#### Stop Conditions
Escalate if:
- Backfill fails after invalidation
- KDSS cannot fulfill with proposed order
- Multiple conflicting orders exist
---
#### Region Reference
| Marketplace | Region |
|-------------|--------|
| NA | us-east-1 |
| EU | eu-west-1 |
| FE | us-west-2 |
---
### 1.13. SOP: Privacy Compliance DLQ Issues
#### Applicability
**Use this SOP when:**
- PrivacyComplianceEventHandlerContainerLambda DLQ alarm
- Error: "Invalid retention days... Retention days cannot be negative"
- GDPR deletion request processing failure
**DO NOT use if:**
- Different Lambda or DLQ
- Error is not about retention days
#### Prerequisites
- Alarm timestamp
- Request ID from logs
---
#### Procedure
##### Step 1: Search for Exception
**Tool:** `CloudWatchLogsTool.searchLogs`
```json
{
"logGroup": "/aws/lambda/PrivacyComplianceEventHandlerContainerLambda",
"query": "fields @timestamp, @message | filter @message like 'Exception while handling Boomerang request' | sort @timestamp desc | limit 20",
"startTime": "",
"endTime": ""
}
```
Extract the `requestId` (format: `SANDFIRE-WORKFLOW-[UUID]`).
---
##### Step 2: Get Request Details
**Tool:** `CloudWatchLogsTool.searchLogs`
```json
{
"logGroup": "/aws/lambda/PrivacyComplianceEventHandlerContainerLambda",
"query": "fields @timestamp, @message | filter @message like '' | sort @timestamp desc | limit 20"
}
```
Extract:
- Customer ID
- Dataset (usually `Kindle.DeviceWarrantyData`)
- Delete Until Time
- Warranty ID (if present)
---
##### Step 3: Query All 3 DynamoDB Tables
**EventSource Table:**
**Tool:** `DynamoDBQueryTool.queryEventSource`
```json
{
"warrantyId": "",
"limit": 20
}
```
Look for `expirationDate` in `WarrantyBackfilled` events.
**KeyTable:**
**Tool:** `DynamoDBQueryTool.queryKeyTableByEntityId`
```json
{
"entityId": "",
"limit": 20
}
```
**DormantWarranties Table:**
**Tool:** `DynamoDBQueryTool.getDormantWarranty`
```json
{
"warrantyId": ""
}
```
---
##### Step 4: Calculate Retention Period
1. **Warranty Expiration Date:** From EventSource analysis
2. **Retention Period:** 10 years from warranty expiration
3. **Expected Deletion Date:** Expiration + 10 years
4. **Current Date:** When request was made
**If current date > expected deletion date:**
- Data should have been auto-deleted but wasn't
- Causes negative retention days calculation
---
##### Step 5: Manual Deletion Required
**REQUIRES HUMAN ENGINEER EXECUTION**
Provide verification summary:
- Warranty ID
- Expiration Date
- Calculated retention period
- Confirmation data is overdue for deletion
Engineer manually deletes the data, then re-drives DLQ.
---
#### Stop Conditions
Escalate if:
- Cannot find warranty expiration date
- Data is NOT overdue for deletion
- Multiple warranties affected
---
#### Important Notes
- Data deletion is IRREVERSIBLE
- Ensure all verifications complete before deletion
- This ensures GDPR compliance
---
#### Region Reference
| Marketplace | Region |
|-------------|--------|
| NA | us-east-1 |
| EU | eu-west-1 |
| FE | us-west-2 |
---
### 1.14. SOP: Unable to Determine Original ASIN
#### Applicability
**Use this SOP when:**
- Error: "Unable to determine original asin so replacement options cannot be provided"
- Error code includes [kla:213aabff]
- BoundEntityUpdated events have `"asin":null`
**DO NOT use if:**
- Device bound to OBA order (use oba-order-binding SOP)
- No warranty exists (use KDSS SOP)
#### Prerequisites
- Device serial number (DSN)
- Warranty ID
---
#### Procedure
##### Step 1: Get Warranty Information
**Tool:** `WarrantyServicesTool.getWarrantiesByDevice`
```json
{
"deviceSerialNumber": "",
"includeClaims": true,
"includeUnboundEW": true,
"includePreviouslyBoundWarranties": true
}
```
Extract the `warrantyId`.
**CRITICAL:** If Customer ID is `A23ZP02F085DFQ`, avoid customer ID-based queries.
---
##### Step 2: Query EventSource Table
**Tool:** `DynamoDBQueryTool.queryEventSource`
```json
{
"warrantyId": ""
}
```
**Look for pattern:**
1. `AmazonDeviceProductBoundToWarranty` - Should have correct ASIN
2. `BoundEntityUpdated` - Shows `"asin":null` (the problem)
---
##### Step 3: Verify Problem Pattern
**Expected pattern:**
- `AmazonDeviceProductBoundToWarranty`: `"asin":"B0XXXXXXXX"` ✓
- `BoundEntityUpdated`: `"asin":null` ✗
**STOP if pattern not found** - different issue, inform engineer.
---
##### Step 4: Extract Correct ASIN
From `AmazonDeviceProductBoundToWarranty` event, extract the correct ASIN.
Optional verification:
**Tool:** `WarrantyServicesTool.getDeviceShipments`
```json
{
"dsn": "",
"deviceType": ""
}
```
---
##### Step 5: Manual Fix Required
**REQUIRES HUMAN ENGINEER EXECUTION**
Provide information for manual EventSource update:
- Warranty ID
- Event IDs of BoundEntityUpdated events with null ASIN
- Correct ASIN from AmazonDeviceProductBoundToWarranty
- Region
- Table: EventSource
---
##### Step 6: Post-Fix Verification
**Tool:** `DynamoDBQueryTool.queryEventSource`
```json
{
"warrantyId": "",
"filterEventName": "BoundEntityUpdated"
}
```
**Verify:** All BoundEntityUpdated events show correct ASIN (not null).
**ONLY post resolution after successful verification.**
---
#### Root Cause
Legacy bug caused ASIN overrides on device FRO events. Bug is fixed, but old data exists with null ASINs.
---
#### Stop Conditions
Escalate if:
- Pattern not found in EventSource
- Multiple conflicting ASINs exist
- Manual update fails
---
#### Region Reference
| Marketplace | Region |
|-------------|--------|
| NA | us-east-1 |
| EU | eu-west-1 |
| FE | us-west-2 |
---
### 1.15. SOP: Warranty Binding Issues
#### Applicability
**Use this SOP when:**
- Extended warranty won't bind to device
- Warranty stuck on previous/wrong device
- Duplicate warranty bindings exist
- "Cannot bind" errors reported
---
#### Issue Type 1: Extended Warranty Stuck on Previous Device
##### When to Use
- Extended warranty bound to old device after replacement
- Error: "Cannot bind to Warranty: [ID] because another binding exists"
##### Procedure
**Step 1: Verify Ownership**
Query BOTH devices using the API operation (preferred - returns CS view):
```json
{
"operation": "GET_WARRANTIES_BY_DEVICE",
"params": { "dsn": "" }
}
```
```json
{
"operation": "GET_WARRANTIES_BY_DEVICE",
"params": { "dsn": "" }
}
```
Note: deviceType is auto-looked up from DIS if not provided.
Verify:
- Same `customerId` on both devices
- Claim history shows device replacement
- Extended warranty order ID matches device order ID
**If different customers or order IDs don't match:** Escalate
**Step 2: Identify Active Binding**
From old device data, find:
- Extended Warranty ID
- Active binding ID (no `unBindTime`)
**Step 3: Invalidate Current Binding**
**Tool:** `WSAOncallOperationsTool.invalidateBinding`
```json
{
"warrantyId": "",
"bindingId": ""
}
```
**Step 4: Bind to New Device**
**Tool:** `WSAOncallOperationsTool.bindExtendedWarranty`
```json
{
"warrantyId": "",
"deviceSerialNumber": "",
"deviceType": "",
"marketplaceId": ""
}
```
**Step 5: Verify**
Query new device, confirm:
- EW shows new device as `associatedDevice`
- New binding in `bindingHistory`
- Previous binding has `unBindTime`
---
#### Issue Type 2: Duplicate Actively Bound Warranties
##### When to Use
- Replacement device has two active limited warranties
- One from previous owner, one from current customer
##### Procedure
**Step 1: Query Device**
Use API operation (preferred):
```json
{
"operation": "GET_WARRANTIES_BY_DEVICE",
"params": { "dsn": "" }
}
```
Identify which warranty belongs to current customer (from ticket).
**Step 2: Invalidate Previous Owner's Warranty**
**Tool:** `WSAOncallOperationsTool.invalidateWarranty`
```json
{ "warrantyId": "" }
```
**Step 3: Verify**
Only one active warranty remains, belonging to current customer.
---
#### Issue Type 3: Extended Warranty Not Compatible with Device Type
##### When to Use
- Error: "Product is not covered by Warranty ASIN"
##### Procedure
**Step 1: Check for Order Binding**
If EW has active binding to order (not device), invalidate it first.
**Step 2: Attempt Regular Binding**
**Tool:** `WSAOncallOperationsTool.bindExtendedWarranty`
**Step 3: If Fails - Escalate**
Force bind requires oncall operation with additional parameters. Escalate with:
- Warranty ID
- Device serial and type
- Error message
---
#### Issue Type 4: Transfer Warranty Back After Claim
##### When to Use
- Customer wants to keep original device
- Warranty transferred to replacement during claim
##### Procedure
**Step 1: Check Both Devices**
Query both original and replacement devices using API operation:
```json
{
"operation": "GET_WARRANTIES_BY_DEVICE",
"params": { "dsn": "" }
}
```
```json
{
"operation": "GET_WARRANTIES_BY_DEVICE",
"params": { "dsn": "" }
}
```
**Step 2: Cancel Claim (if needed)**
**Tool:** `WSAOncallOperationsTool.cancelClaim`
```json
{ "claimId": "" }
```
**Step 3: Transfer Warranty**
Use the API operation for transferring warranty after canceled claim:
```json
{
"operation": "TRANSFER_LIMITED_WARRANTY_FOR_CANCELED_CLAIM",
"params": {
"warrantyId": "",
"dsn": ""
}
}
```
Note: deviceType is auto-looked up from DIS if not provided.
**Step 4: Verify**
Query the original device again to confirm warranty is now bound:
```json
{
"operation": "GET_WARRANTIES_BY_DEVICE",
"params": { "dsn": "" }
}
```
---
#### Decision Matrix
| Scenario | Action |
|----------|--------|
| Same customer, matching orders, claim history | Proceed |
| Same customer, no clear indicators | Escalate |
| Different order IDs | Escalate |
| Different customers | Stop - do not proceed |
---
#### Stop Conditions
Escalate if:
- Devices belong to different customers
- Order IDs don't match
- Tool returns unexpected error
- Verification shows unexpected state
---
### 1.16. SOP: Warranty Deletion Issues (Old Devices)
#### Applicability
**Use this SOP when:**
- Error: "Error occurred while determining warranty claim eligibility codes"
- Error suggests device "has already been replaced by a different device"
- Device is more than 10 years old
**DO NOT use if:**
- Device is less than 10 years old
- Warranty exists but has other issues
#### Prerequisites
- Device serial number (DSN)
- Device type
---
#### Procedure
##### Step 1: Check Device Shipment Date
**Tool:** `WarrantyServicesTool.getDeviceShipments`
```json
{
"dsn": "",
"deviceType": ""
}
```
**Check:** Was device shipped more than 10 years ago?
---
##### Step 2: Confirm Warranty Deletion Status
**Tool:** `WarrantyServicesTool.backfillLimitedWarranty`
```json
{
"deviceSerialNumber": "",
"deviceType": ""
}
```
**If response includes:** `"warrantyStatusCode": "WARRANTY_DELETED"`
- Confirms warranty was deleted due to age
---
##### Step 3: Inform Customer Service
**Resolution:** Warranty cannot be recovered.
**Response to CS:**
```
The device warranty has been permanently deleted from the system due to its age
(over 10 years old). The device is no longer eligible for warranty service.
Device Information:
- Serial Number: [DSN]
- Ship Date: [DATE]
- Status: WARRANTY_DELETED
Alternative options should be discussed with the customer.
```
---
#### Key Points
- Warranties are deleted after 10 years (data retention policy)
- Deleted warranties CANNOT be recovered
- Error message about "replaced by different device" is misleading
- Actual cause is warranty deletion due to age
---
#### Stop Conditions
This SOP is informational. No fix is possible for deleted warranties.
If CS requires further assistance:
- Confirm device age
- Explain data retention policy
- Suggest alternative customer resolution options
---
### 1.17. SOP: Warranty Type & Configuration Mismatches
#### Applicability
**Use this SOP when:**
- Warranty shows as Limited but should be Worry Free
- Claim limit reached (3 claims) but warranty is not expired
- RCH/OBA order has wrong warranty type due to marketplace mismatch
- Error: "Error retrieving EW Warranty Configuration for marketplace"
- CS reports warranty duration is incorrect
**DO NOT use if:**
- Warranty is missing entirely (use kdss-order-identification SOP)
- G2S2 config is missing for an ASIN (use g2s2-config-fallback SOP)
- Warranty dates are wrong on refurbished device (use certified-refurbished SOP)
#### Prerequisites
- Device serial number (DSN)
- Marketplace context from the ticket
---
#### Issue Type 1: Claim Limit Reached
##### When to Use
- Warranty shows Out of Warranty (OOW) but expiration date has not passed
- Customer has made 3 claims on the same limited warranty
- Limited warranties have a hard-coded claim limit of 3
##### Procedure
**Step 1: Verify Warranty State**
```json
{
"operation": "GET_WARRANTIES_BY_DEVICE",
"params": { "dsn": "" }
}
```
Confirm warranty is not expired but shows OOW. Check claim history — if 3 claims exist, this is the cause.
**Step 2: Inform CS**
The claim limit of 3 is hard-coded for limited warranties (Worry Free warranties have unlimited claims). There is no WSA fix. Direct CS to issue an exception replacement.
**Note:** This is expected behavior, not a bug.
---
#### Issue Type 2: RCH/OBA Order — Wrong Warranty Type (Should Be Worry Free)
##### When to Use
- Device is typically in JP marketplace
- Kids Edition Tablet (KET) or similar device that should have Worry Free warranty
- Warranty shows as Limited with 1-year expiration instead of Worry Free with 2-year
- Order is an offline purchase (RCH or OBA order)
##### Procedure
**Step 1: Verify Current State**
```json
{
"operation": "GET_WARRANTIES_BY_DEVICE",
"params": { "dsn": "" }
}
```
Confirm warranty type is LIMITED when it should be WORRY_FREE.
**Step 2: Check Order Type**
```json
{
"operation": "QUERY_KEY_TABLE_BY_DEVICE",
"params": { "dsn": "" }
}
```
Look at the order ID. If it starts with `RCH-` or `OBA-`, this confirms the root cause: KDSS fulfills all offline orders as NA marketplace, so WSA looked up config in NA instead of the correct marketplace (e.g., JP).
**Step 3: Escalate for Marketplace Update**
The fix is to update the warranty configuration using the correct marketplace. Provide the oncall engineer with:
- Warranty ID
- DSN and Device Type
- Correct marketplace ID (e.g., `A1VC38T7YXB528` for JP)
**Oncall engineer** can use WSA Tools to pull up the warranty and select the correct marketplace, which will fetch the Worry Free configuration and update the warranty.
---
#### Issue Type 3: Warranty Type Incorrect (LW vs Worry Free)
##### When to Use
- Device should have Worry Free warranty but shows Limited
- Not an RCH/OBA order (online purchase)
- Configuration may be wrong or ASIN mapping may be incorrect
##### Procedure
**Step 1: Verify Current State**
```json
{
"operation": "GET_WARRANTIES_BY_DEVICE",
"params": { "dsn": "" }
}
```
**Step 2: Check Event History**
```json
{
"operation": "QUERY_EVENT_SOURCE",
"params": { "warrantyId": "" }
}
```
Look at the original warranty creation event. Check if the ASIN is correct and if the warranty type was set correctly at creation.
**Step 3: Escalate**
If the ASIN is correct but warranty type is wrong, this is a G2S2 configuration issue. Escalate to the Limited Warranty Onboarding POC (jadrajat@) or Extended Warranty Onboarding POC (kulsonam@) with:
- ASIN
- Marketplace ID
- Current warranty type vs expected warranty type
---
#### Issue Type 4: Error Retrieving EW Config (Wrong Marketplace)
##### When to Use
- Error: "Error retrieving EW Warranty Configuration for marketplace 'X', asin 'Y'"
- Customer has unbound EW purchased in a different marketplace
- CS is accessing CSCentral from a different marketplace than where EW was purchased
##### Procedure
**Step 1: Find the EW**
```json
{
"operation": "GET_EXTENDED_WARRANTIES_BY_CUSTOMER",
"params": { "customerId": "" }
}
```
Identify the unbound EW and note its ASIN and the marketplace it was purchased in.
**Step 2: Identify Marketplace Mismatch**
The error occurs because WSA uses the marketplace from the CS request (CSCentral marketplace), not the EW purchase marketplace, when looking up G2S2 config. If the EW was bought in UK but CS is filing from US, the config lookup fails.
**Step 3: Inform CS**
Direct the CS representative to file the claim through the correct CSCentral marketplace — the one where the EW was purchased. This will resolve the config lookup error.
---
#### Stop Conditions
Escalate if:
- Warranty type is wrong and root cause is unclear
- G2S2 configuration needs to be updated
- Multiple devices/customers affected by the same config issue
---
### 1.18. SOP: WSA Self Replacement Null Fields
#### Applicability
**Use this SOP when:**
- Error: "Cannot invoke Currency.getUnit() because ReplacementOption.getListPrice() is null"
- CloudWatch shows replacement option with mostly null fields
- Only `asin`, `costToCustomer`, `isValidOption` are populated
**DO NOT use if:**
- No replacement options at all (use no-replacement-options SOP)
- Error is about ASIN determination (use unable-to-determine-original-asin SOP)
#### Prerequisites
- Device serial number (DSN)
- Selected component ASIN
- Marketplace ID
- Error timestamp
---
#### Procedure
##### Step 1: Search CloudWatch for Error
**Tool:** `CloudWatchLogsTool.searchLogs`
```json
{
"logGroup": "WSAMainLogs",
"query": "fields @timestamp, @message | filter @message like 'GetReplacement' and @message like '' | sort @timestamp desc"
}
```
**Look for log showing:**
- `listPrice=null`
- `offerListingId=null`
- `merchantId=null`
- Only populated: `asin`, `costToCustomer`, `isValidOption`
---
##### Step 2: Confirm Self-Replacement Scenario
This occurs when:
1. KRIS returns no device replacement options
2. Selected component has no deviceType
3. System creates "self replacement option"
4. No offer found for ASIN in marketplace
5. Fields remain null → downstream NPE
---
##### Step 3: Reassign to ADRL Team
**This requires ADRL configuration, not WSA fix.**
**Provide to ADRL:**
- Selected Component ASIN
- Marketplace ID
- Device Type
- Error: Self-replacement option created with null fields
- Root Cause: No KRIS configuration and no offers available
- Required Action: Configure ASIN in KRIS/G2S2 for this marketplace
---
#### Root Cause
Configuration gap in KRIS/G2S2:
- Missing KRIS configuration for the ASIN
- No offers available in the marketplace
- Self-replacement fallback creates incomplete data
---
#### Stop Conditions
Escalate if:
- Error is different than expected
- ADRL reports configuration exists
- Issue affects multiple ASINs
---
#### Region Reference
| Marketplace | Region |
|-------------|--------|
| NA | us-east-1 |
| EU | eu-west-1 |
| FE | us-west-2 |
---
## 2. Alarms
### 2.1. SOP: 5XX TransferLW for CanceledClaim Alarm
#### Applicability
**Use this SOP when:**
- Alarm: `5XXError: TransferLimitedWarrantyForCanceledClaim-prod.*`
- 5XX errors on TransferLimitedWarrantyForCanceledClaim API
**DO NOT use if:**
- 5XX errors on other APIs (use general 5XX alarm investigation)
- Alarm is for BackfillLimitedWarrantyV2 (use kdss-order-identification SOP)
---
#### Procedure
##### Step 1: Check Error Volume and Timing
```json
{
"operation": "QUERY_CLOUDWATCH_LOGS",
"params": {
"queryString": "fields @timestamp, @message | filter @message like /ActivityCleanupInterceptor InvocationException, throwing to client/ | filter @message like /TransferLimitedWarrantyForCanceledClaim/ | stats count(*) as failures by bin(5m) | sort @timestamp desc",
"startTime": "",
"endTime": ""
}
}
```
##### Step 2: Identify the Failing DSNs
```json
{
"operation": "QUERY_CLOUDWATCH_LOGS",
"params": {
"queryString": "fields @timestamp, @message | filter @message like /does not have an active Claim to cancel to transfer Warranty back to Product:/ | stats count(*) as attempts by @message | sort attempts desc | limit 20",
"startTime": "",
"endTime": ""
}
}
```
##### Step 3: Analyze Pattern
**CSA Retry Pattern (most common):**
- Same DSN appears repeatedly during the alarm window
- Error: "Warranty: [X] does not have an active Claim to cancel to transfer Warranty back to Product: [X]"
- This means a CSA is trying to cancel an already-canceled claim multiple times
**If same DSN repeats:** This is transient — CSA troubleshooting behavior. No action needed.
**If multiple different DSNs:** Investigate further — may indicate a systemic issue.
##### Step 4: Resolution
**If CSA retry confirmed:**
- Close ticket with explanation: "Logs confirm transient 5XX errors caused by CSA attempting to cancel an already-canceled claim on DSN [X] multiple times during troubleshooting. No systemic issue."
**If not CSA retry:**
- Escalate for deeper investigation
---
#### Stop Conditions
Escalate if:
- Multiple different DSNs are failing
- Error pattern does not match CSA retry behavior
- 5XX errors are ongoing and increasing
---
### 2.2. SOP: DynamoDB High TPS Alarm Analysis
#### Applicability
**Use this SOP when:**
- Ticket references DynamoDB high TPS alarm
- Alarm mentions customerIDIndex TPS spike
- CloudWatch alarm for DDB throttling
**Common Alarm Names:**
- `WSA-DDB-CustomerIDIndex-HighTPS`
- `WarrantyServices-DDB-Throttling`
---
#### Procedure
##### Step 1: Get Alarm Details
**Tool:** `CloudWatchLogsTool.getAlarmState`
```json
{
"alarmNamePrefix": "WSA-DDB",
"stateValue": "ALARM"
}
```
Note: Alarm name, trigger time, affected table/index
---
##### Step 2: Query Logs for TPS Source
**Tool:** `CloudWatchLogsTool.queryLogs`
```json
{
"logGroupName": "/aws/lambda/WarrantyServices-API",
"queryString": "fields @timestamp, @message, customerId | filter @message like /customerIDIndex/ | stats count(*) as requestCount by customerId | sort requestCount desc | limit 20",
"startTime": "",
"endTime": ""
}
```
Look for customer IDs with unusually high request counts.
---
##### Step 3: Check Known Test Customer IDs
**Game Day Test Customer IDs:**
- `AAUN6GRDK1Y6Y`
- `A1996B4MGPVTDP`
- `A3I1OCZ3CE1A7S`
If high-TPS customer matches → Likely Game Day testing
---
##### Step 4: Analyze Pattern
**Tool:** `CloudWatchLogsTool.queryLogs`
```json
{
"logGroupName": "/aws/lambda/WarrantyServices-API",
"queryString": "fields @timestamp, @message | filter customerId = '' | stats count(*) as calls by bin(5m) | sort @timestamp",
"startTime": "",
"endTime": ""
}
```
**Game Day indicators:**
- Sudden spike then drop
- Concentrated in short window
- Matches known test IDs
---
##### Step 5: Resolution
**If Game Day Testing Confirmed:**
- No action required - expected test traffic
- Monitor for recurrence outside test windows
**If NOT Game Day Testing:**
- Escalate for investigation
- Include: alarm name, trigger time, customer ID, request pattern
---
#### Example
**Ticket:** V1998698335
**Analysis:**
1. Alarm: WSA-DDB-CustomerIDIndex-HighTPS
2. Found customer `AAUN6GRDK1Y6Y` with 50,000+ requests in 10 minutes
3. Customer ID matches known Game Day test ID
4. Pattern: sudden spike, immediate drop
**Resolution:** Confirmed Game Day testing, no action required
---
---
#### Additional Scenario: KeyTable Main Index High RCU Alarm
##### When to Use
- Alarm: `DDB HighConsumedReadCapacity KeyTable`
- High RCU spike on the main index (not customerIDIndex)
##### Root Cause
RCUs spike if there is high TPS of queries OR if a consistent TPS of queries suddenly returns a lot of data. A customer with many test devices (e.g., 30+ devices) can cause massive data returns per query, spiking RCUs.
##### Procedure
**Step 1:** Check if WSA was called for known high-data customer IDs (same as Step 3 above).
**Step 2:** If not a known test customer, trace through code paths that invoke the KeyTable. Look for requests with high latency on methods annotated with `@TimeAndCountMetrics`:
```json
{
"operation": "QUERY_CLOUDWATCH_LOGS",
"params": {
"queryString": "fields @timestamp, @message | parse @message '\"*.Time\":*,' as method, latency | filter latency > 5000 | sort latency desc | limit 20",
"startTime": "",
"endTime": ""
}
}
```
**Step 3:** Identify which requests caused the spike and whether it's transient or ongoing.
---
#### Stop Conditions
Escalate if:
- Cannot query CloudWatch logs
- Customer ID not in known test list AND pattern unclear
- TPS spike is ongoing
- Multiple customer IDs showing high TPS
---
### 2.3. SOP: Missing Marketplace Configuration Alarm
#### Applicability
**Use this SOP when:**
- Error: "No Canonical_marketplace_id for encryptedMarketPlaceId"
- Error: "No lwconfigs for marketplace `###`, devASIN `default`"
- Error: "Something unexpected went wrong when determining Limited Warranty period"
- New marketplace launched at Amazon but G2S2 config not updated
**DO NOT use if:**
- Error is about a specific ASIN config (use g2s2-config-fallback SOP)
- Error is about EW config marketplace mismatch (use warranty-type-mismatch SOP)
---
#### Procedure
##### Step 1: Confirm the Error Pattern
```json
{
"operation": "QUERY_CLOUDWATCH_LOGS",
"params": {
"queryString": "fields @timestamp, @message | filter @message like /No Canonical_marketplace_id for encryptedMarketPlaceId/ | stats count(*) as occurrences by bin(1h) | sort @timestamp desc",
"startTime": "",
"endTime": ""
}
}
```
##### Step 2: Extract the Missing Marketplace ID
```json
{
"operation": "QUERY_CLOUDWATCH_LOGS",
"params": {
"queryString": "fields @timestamp, @message | filter @message like /No Canonical_marketplace_id for encryptedMarketPlaceId/ | sort @timestamp desc | limit 10",
"startTime": "",
"endTime": ""
}
}
```
Extract the `encryptedMarketPlaceId` value from the log message.
##### Step 3: Escalate for Marketplace Update
This requires updating the `@KWSConfig_Live` Label Stream in G2S2 with the new marketplace mapping. Provide the oncall engineer with:
- The encrypted marketplace ID from the logs
- Error frequency and start time
- Link to marketplace update instructions: https://w.amazon.com/bin/view/KiSIT/Secure/KindleWarrantyService/Marketplace_Changes/
---
#### Stop Conditions
Escalate if:
- Multiple marketplace IDs are missing
- Error volume is high and increasing
- Cannot identify the encrypted marketplace ID from logs
---
## 3. Human-Only Documentation
### 3.1. Andes Table Data Quality Issues
Tickets with "RSE_COPY_VALIDATION_ISSUE" indicate published data violating the Andes table schema.
Reference: https://t.corp.amazon.com/V787620038
#### Procedure
1. **Identify bad data:** Follow https://w.amazon.com/bin/view/BDT/Products/Andes3.0/Subscriptions/Datashare_DQ/#HHowtoExamineBadRecordfromInfoinTicket
2. **Find all corrupted records:** Use Cradle (https://datacentral.a2z.com/cradle#/WarrantyServices/profiles) with manual query profile. Output to S3 bucket `wsa-andes-data-bucket`.
3. **Fix bad data** manually or via appropriate method
4. **Republish** using oncall lambda redrive for affected warranties
5. **Create new table version** at https://datacentral.a2z.com/providers/kws (bad data is stuck in the stream — fixing source doesn't fix stream)
6. **Pause DataCraft pipeline** > Create new version (backfill from Andes) > Wait for completion > Mark Active > Update pipeline destination > Re-enable > Deprecate old version
---
### 3.2. Edge Cases (Manual Fixes)
Issues requiring direct database edits, external tools, or manual intervention.
#### Force Limited Warranty Binding to be Active
Old KWS warranty (`Warranty-XXXXXXXXXX`) with no active bindings.
1. Query Warranty ID in Event Source
2. Find first `WarrantyBackfilled` event
3. Set `isActive` to `true` (no quotes), `unbindTime` to `null` (no quotes)
4. Only edit Event Source, NOT the MV. Remove stray `"` or `"/` characters.
5. Redrive warranty to MV if needed.
#### KET Device with Wrong ASIN
Online: Use https://spectator-g7g.amazon.com/FionaSpectatorService/FulfillFiona.jsp with correct KET ASIN. Device gets deregistered — CS must re-bind.
Offline: Cannot refulfill. Ask Concessions for exception.
#### Different DSN Than Expected Shipped
Option 1 (preferred): Manually write correct DSN into database (preserves history).
Option 2: Refulfill with correct DSN (creates new LW, loses history).
#### Echo Buds Multi-Component EW Replacement
EW can only bind to one component. Extend LW coverage for excess components. Long-term: WSA-1756.
#### EW Wrong Expiration Date
Have CS file exception. Tracked: https://sim.amazon.com/issues/KindleWarrantyService-494
#### BI Duplicate Data
Find claimId > search Event Source EntityIdIndex for `Claim-` > get warrantyId > oncall lambda RERUN_DATA_PUBLICATION with correct table (CLAIM, WARRANTY_MAIN, or EXTENDED_WARRANTY).
#### BuyNewEW Alarm / SquareTrade Issues
If BuyNewEW volume drops to 0, contact @kulsonam for SquareTrade coordination. Treat as Sev2.5.
Reference COEs: https://www.coe.a2z.com/coe/254929/content
SquareTrade merchant: `amzn1.merchant.o.A3B4VRMPOFUHJ3`
FRPG permissions: `tortuga-viewer-uci` LDAP
#### Client Onboarding (IAM Auth)
Wiki: https://w.amazon.com/bin/view/WarrantyServices/PartnerTeams/Onboarding/
NAWS clients: https://code.amazon.com/packages/WarrantyServicesCDK/blobs/mainline/--/lib/authentication/clients/configuration/AWSPrincipalClientsConfig.ts
MAWS clients: https://code.amazon.com/packages/WarrantyServicesCDK/blobs/mainline/--/lib/authentication/clients/configuration/TurtleClientsConfig.ts
Note: Turtle ignores parent DEV-DSK hostclass — each DEV-DSK must be onboarded individually.
---
### 3.3. G2S2 & RMP Configuration
#### G2S2 Overview
G2S2 stores WSA warranty configuration. Editor: https://g2s2-editor.amazon.com/editor/#n=25&p=0&t=tables&sv=%40KWSConfig_Live
##### Key Tables
- `klaw_kws_limit_warranty_configs` — Limited warranty configs
- `klaw_kws_deviceasins` — Device ASINs (must exist before LW config)
- `klaw_kws_extend_warranty_configs` — Extended warranty configs
##### Permissions
- Table/label permissions: https://g2s2.corp.amazon.com/secureAuthoring
- Direct access: https://bindles.amazon.com/software_app/KindleWarrantyService
#### Warranty Onboarding Procedure
1. Download CSV/XLSX from onboarding SIM
2. Convert to CSV if needed, validate in text editor (no empty lines, proper quoting)
3. Upload to S3: https://s3.console.aws.amazon.com/s3/buckets/warranty-configuration-lambda-bucket-prod
4. Check Lambda logs for success
5. Verify in G2S2 by searching uploaded ASINs
#### RuleManagementPlatform (RMP)
Rulesets: https://rmp-na.amazon.com/?region=USAmazon&ruletype=ReplacementOptionsRuleset&schema=WarrantyServicesSchema
##### Modifying Rulesets
1. Click Live Ruleset Instance ID > Find rule > Edit > Save > Validate
2. Commit changes > Promote to AUDITING > Approve > Promote to LIVE
3. Repeat for all marketplaces
4. Update wiki: https://w.amazon.com/bin/view/WarrantyServices/BusinessRulesManagement/
---
### 3.4. Infrastructure Emergencies
#### Prod Stack Deletion
Impact depends on resources in the stack:
- **Deterministic physicalIds:** Emergency deployment from Gamma to Prod
- **Dynamic endpoints (API Gateway):** See API Gateway section below
- **VPC with BubbleBridge:** See BubbleBridge section below
##### BubbleBridge Stack Deletion
Reference COE: https://www.coe.a2z.com/coe/232378/content
Rolling back DOES NOT WORK — VPC gets recreated with a new VPC ID. Mitigation: roll back to recreate VPC, then perform emergency BubbleBridge onboarding with the new VPC.
##### API Gateway Stack Deletion
Reference COE: https://www.coe.a2z.com/coe/235124/content
API Gateway dynamically generates endpoint URLs. WSA provides a static DNS that resolves to the dynamic endpoint. If re-deployed, DNS resolution must be updated.
#### Lambda OOM Metaspace
AWS Lambda hardcodes MaxMetaspaceSize to 10% of configured memory. Above 90% usage causes OutOfMemoryError.
**Short-term:** Lambda > Configuration > General Configuration > Increase memory > Publish new version > Weighted alias cutover
**Long-term:** Increase Lambda memory in CDK.
#### MaterializedView / DormantWarranty StreamHandler Errors
##### Iterator Age Alarm
DDB Stream messages expire after 24 hours. Causes:
1. Queue filling faster than processing — increase parallelization factor on Lambda trigger
2. Lambda stuck on a record — investigate, potentially direct prod push (2-person rule)
##### Lambda Failures / DLQ Alarms
Failed messages go to RecordFetcherFunction then retry lambda. Likely malformed warranty requiring manual intervention. DLQ build-up > 24 hours = data loss risk.
##### DataFetcherDLQ Sev2
Manual recovery with `aws dynamodbstreams get-shard-iterator` and `get-records`. If recovered, send to RecordQueue and delete from DLQ.
#### Scaling Service
Wiki: https://w.amazon.com/bin/view/WarrantyServices/Oncall/Scaling
Emergency scaling: https://w.amazon.com/bin/view/WarrantyServices/Oncall/Scaling#HEmergencyWSAScaling
#### Disabling Lambda/SQS Connection
Lambda > active version/alias > Configuration > Triggers > Edit > Uncheck "Activate Trigger" > Save
#### Billing Alarm
Billing metrics accumulate in us-east-1. Check "All > Billing > By Service" to identify spiking resource. Dashboard: https://w.amazon.com/bin/view/WarrantyServices/Internal/Dashboards/InternalMonitoring/Prod/NA/
---
### 3.5. Oncall Reference
Quick reference for oncall engineers covering policies, tools, contacts, and triage procedures.
#### Going On Call
- Read recent oncall handoffs: https://quip-amazon.com/lFo0OofzQFg0/KWS-On-call-Handoffs
- Review dashboards: https://w.amazon.com/bin/view/WarrantyServices/Internal/Dashboards/
#### Triage Checklist
1. Check system health (5 min) via dashboards. Check all prod regions for drops/spikes.
2. Work trouble ticket queues: https://t.corp.amazon.com/issues/?q=extensions.tt.status%3A%28Assigned%20OR%20Researching%20OR%20%22Work%20In%20Progress%22%20OR%20Pending%29%20AND%20extensions.tt.assignedGroup%3AWarrantyServices
3. Priority: Sev2 > Customer-facing > Internal customer-facing > Onboardings with deadlines > Maintenance
#### Production AWS Account Best Practices
- Access Prod via https://conduit.security.a2z.com/accounts (defaults to read-only)
- Use `WSADeveloperOncallRole` instead of Admin — it DENIES deletion on critical resources
- Bindle: https://bindles.amazon.com/resource/amzn1.bindle.resource.vv6lzzillbxxkebjpzvq
- Log out of Prod when done
- Minimize working in both dev and Prod accounts simultaneously
- Prod stack deletion requires 2-person operation (termination protection must be manually disabled first)
#### Conduit Down Workaround
https://w.amazon.com/bin/view/ConsumerCloudTrust/Conduit/Features/ConduitWebsite/FAQ#HIfconduitwebsiteisdown2ChowcouldIaccessmyAWSaccount3F
#### Coral Service Warning
When sending payloads to WSA Coral Service via BOTO3/CLI: Coral uses **epoch seconds** for timestamps. Using epoch milliseconds will set dates far in the future and BREAK WSA. See: https://sage.amazon.com/questions/25905
#### Ticket Tags in Use
| Tag | Description |
|-----|-------------|
| Un-cancel Claim | Claim cancellation reversal |
| KRIS ASIN Update | KRIS replacement ASIN issue |
| KDSS Data Issue | KDSS fulfillment data problem |
| Missed SOP | CS missed standard procedure |
| EW Binding Eligibility | EW binding issue |
| WSA Tools Feature Gap | Missing WSA Tools functionality |
| Dormant Warranty | Dormant warranty issue |
| Dormant Warranty - GetWarrantyClaimCode | Dormant warranty blocking claim codes |
| EW Previously Bound | EW already bound to another device |
| Invalidated Warranty | Warranty incorrectly invalidated |
| KWS Warranty | Legacy KWS warranty issue |
| FRO ASIN | First Radio On ASIN issue |
| Failed Shipment | Shipment delivery failure |
| JP Worry Free | JP marketplace Worry Free issue |
| RCH Order | Offline purchase order |
| OBA Order | Out of Box Audit order |
#### CTIs and Resolver Groups
- **KDSS:** Digital Media Technology / Kindle Device Sales / KindleDeviceSalesService
- Wiki: https://w.amazon.com/bin/view/DCS_Chennai/DeviceManagementService/KindleDeviceSalesService
- Oncall: https://oncall.corp.amazon.com/#/view/dmsbifrost-dev-primary/schedule
- **KRIS:** Digital Media Technology / Kindle Reverse Logistics Tech / Kindle Replacement Info Service
- **D2Concessions:** Customer Service / CSC/Texas / D2Concessions
- Office Hours: https://w.amazon.com/bin/view/D2AS/Technology/D2Concessions/ContactUs
- **CE Tech Warranties:** https://w.amazon.com/bin/view/Warranties/Contact
#### Warranty Onboarding POCs
- **Limited Warranty:** jadrajat@
- **Extended Warranty:** kulsonam@
#### Tools
| Tool | URL | Purpose |
|------|-----|---------|
| WSA Tools | https://tools.warranty-services.devices.amazon.dev/ | Primary troubleshooting UI |
| Cedric (AI) | https://console.harmony.a2z.com/internal-ai-assistant?persona=09ebf5bc-6347-4414-a300-abe900441f83 | Chat-based troubleshooting |
| OnCall Lambda | See wiki | Low-level WSA operations |
| DMS-360 | https://dms-360.aka.amazon.com/ | Device Type / ASIN mappings |
| Grass | https://grass.integ.amazon.com/ | Order/purchase/shipment lookup |
| CSCentral | https://cscentral.amazon.com | CS representative portal |
| Amazon Translate | https://translate.amazon.com | Internal translation |
| G2S2 Editor | https://g2s2-editor.amazon.com/editor/ | Warranty configuration |
#### Common Informational Responses
**EU 2-year warranty law:** Tell CS to override on their end. Tag: "Missed SOP"
**CSCentral cached warranty duration:** CSCentral displays cached values. Assure CS they can likely file a replacement.
**Cannot make claim due to active service event:** Warranty is already being replaced. Reassign to RL Tech team.
**5XX RegisterWarrantyClaim from KROBS:** KROBS sends bad data when clearing backlog. If only KROBS calls fail and Slapshot is fine, mark as false alarm.
---
### 3.6. Pipeline & Deployment
#### Packaging Approval Workflow Failed
When adding new resources or pipeline changes, manually approve changes in the approval workflow.
#### New Lambda Deployment S3 Error
Chicken-and-egg problem:
1. Send another deployment through packaging stage (can be empty build request)
2. If still failing, completely delete the stack and retry from Pipelines UI
3. WSA CDK often retains resources on deletion — delete ALL retained resources AND the stack
#### NAWS Pipeline Rollback
1. Pipeline > Emergency Actions > Single Target Rollback
2. Select stage > last approved version > Preview Rollback
3. Verify diff > Provide reason > Initiate Rollback
4. Monitor CloudFormation: `UPDATE_COMPLETE` = done; `UPDATE_ROLLBACK_FAILED` = click ContinueUpdateRollback
#### Fixing Broken Version Set
Reference: https://sim.amazon.com/issues/WSA-2442
1. Merge `WarrantyServices/release` into `WarrantyServices/release-PipelineFix`
2. Merge from `live` into PipelineFix
3. Prune broken packages
4. Pull locally (new workspace), fix (typically `bb app updateSnapshot`)
5. Publish CR, merge, then manually build into VS
6. Switch workspace back to `WarrantyServices/release`
#### Manually Uploading Lambda Code (2-PERSON REVIEW)
1. Clean, currently-live workspace
2. `bats transform -x AWSLambda-1.0 -t package-MajorVersion -p package-MajorVersion`
3. Upload zip to S3 (same region as Lambda)
4. Lambda > Code > Upload From > S3 link
5. If using alias, cutover to new version
#### Manually Uploading Docker Code (2-PERSON REVIEW)
1. Clean, currently-live workspace
2. `bats transform -x DockerImage-1.0 -t WarrantyServicesLambda-1.0 -p WarrantyServicesLambda-1.0`
3. Tag and push to ECR, update Task/Service, force new deployment
---
### 3.7. Privacy Compliance (Boomerang / AEDU / SandFire)
#### Overview
WSA handles GDPR compliance through Boomerang, processing requests from AEDU (DSAR) and SandFire/OD3 (Data Deletion).
Lambda code: https://code.amazon.com/packages/WarrantyServicesPrivacyComplianceLambda/trees/mainline
#### Redriving Failed Requests
1. Go to Boomerang: https://boomerang.corp.amazon.com/#/workflow-explorer
2. Use Boomerang Workflow ID (from ticket) or service-specific ID
3. Request Type: `GDPR.Delete` (SandFire) or `GDPR.DSAR` (AEDU)
4. Team: WarrantyServices
##### Finding AEDU Request IDs
Portal: https://portal.aedu.privacy.a2z.com/ > Retail-DSAR > Data Owners > WarrantyServices > Data Requests
The redrive ID is the UUID in the nav header.
#### Testing
##### Beta
- AEDU: https://portal.beta.aedu.privacy.a2z.com/ > Create Data Request
- OD3: https://portal.data-deletion.privacy.a2z.com/ > Workflow Validation > New Request (Beta)
##### Gamma
- AEDU: https://portal.gamma.aedu.privacy.a2z.com/
- OD3: Same portal, select Gamma
#### Changing DSAR Response Schema
CDK: https://code.amazon.com/packages/WarrantyServicesCDK/blobs/mainline/--/lib/stacks/PrivacyComplianceInfraStack.ts
Steps: Modify Lambda response > Update Boomerang UI columns > Deploy > Test via AEDU portal
Production cutover: Block promotions > Pause queue > Update Boomerang schema > Deploy > Re-enable queue > Redrive failures
---