Error Analysis & Troubleshooting Guide

by Admin 39 views
Error Case Analysis and Troubleshooting Guide

Hey guys! Let's dive into some common errors we've been seeing and how to tackle them. We'll break down the issues by platform, so you can easily find the info you need. Understanding these errors is key to keeping things running smoothly, so grab a coffee and let's get started!

Common Errors

**StockLockAcquireFailException**

This one pops up a lot, but don't sweat it too much. It's a debug log, meaning it doesn't get sent over to OCI. So, while it's frequent, it's not a showstopper. Keep an eye on the logs, but it shouldn't be causing major disruptions. It is necessary to periodically check for the cause and if necessary improve the code.

**java.net.SocketTimeoutException: Read timed out**

This **SocketTimeoutException** rears its head from time to time. This is something that we need to keep an eye on because it can be an intermittent problem. It indicates that a read operation took too long, suggesting potential network issues or slow responses from the server. It's a good idea to investigate these occurrences to ensure they don't become a persistent problem. Maybe there is a problem with the network, so it is necessary to test it.

SHOPEE Errors

**error=error_server, message=System error. Please try again later.**

This **Shopee error** appears intermittently. It's suspected to be related to instability in the Shopee test environment. It seems to be happening only in local and test environments so far and can occur with any API. It's a frequent visitor, so keep it in mind when you're testing. The most important thing is to improve the stability of the test environment.

LAZADA Errors

**error=ApiCallLimit, message=Api access frequency exceeds the limit. this ban will last 1 seconds**

We see this **Lazada API call limit** error from time to time, likely due to temporary issues in the test environment. Interestingly, it seems to happen only with the /orders/get API. The **Lazada API** has limitations in requests per second. Let's dig deeper to figure out what's causing it.

  • Timeline of Errors: Here's a look at when we've seen this error:
    • 2025-06-18 03:00:03
    • 2025-06-23 05:00:03
    • 2025-06-27 08:30:05
    • 2025-06-29 04:00:04
    • 2025-06-30 14:00:03
    • 2025-06-30 15:00:04
    • 2025-06-30 18:00:03
    • 2025-06-30 21:00:03
    • 2025-06-30 21:00:05
    • 2025-06-30 21:00:06
    • 2025-06-30 22:00:07

If we were exceeding the daily API call limit, we'd expect errors throughout the day, but that's not what we're seeing. Although the daily limit is 10,000 calls, we're only making around 1,000 calls a day.

Looking at the Lazada documentation (https://open.lazada.com/apps/doc/doc?nodeId=30715&docId=121320), it explains that each API has its own calls per second limit. This could be a factor, however, the fact that the errors don't consistently occur under the same conditions is peculiar.

For example:

  • On 2025-06-18 at 03:00:02, the call was successful. But at 03:00:03, the error happened. Then, at 03:00:06, it was successful.
  • On 2025-06-23, a similar pattern emerged: one call failed, but others didn't.
  • On 2025-06-27, errors occurred after two calls, but not earlier when the same was done.

This inconsistency makes it difficult to pinpoint the exact cause.

Lazada's Response:

The number of API calls per second for an open platform API is limited. If the API has already reached its call limit for the current second, this error will occur, and you will need to wait until the next second to retry.

By the way, the number of calls per second for each API varies. The QPS for /orders/get in your request is 2000, meaning that this API can be called 2000 times per second.

While Lazada says it's about exceeding the per-second limit, which is 2,000 calls per second for /orders/get, it's still unclear why we're seeing these errors.

**error=6, message=redis.clients.jedis.exceptions.JedisExhaustedPoolException: Could not get a resource since the pool is exhausted request id : 2101444217513307059102254edfda**

Error code 6 signifies an unexpected internal error within Lazada's system. This is a temporary glitch. There's not much we can do on our end, so if it persists, we'll need to reach out to Lazada support. This means the Redis connection pool is exhausted, likely due to heavy load or a problem with the Redis server itself.

Here are some of the times this error occurred:

  • 2025-07-01 08:45:06

**[LazadaServiceClient#getLazadaOrders] <--- ERROR SocketTimeoutException: Connect timed out (11209ms)**

This **Lazada timeout error** is happening frequently as of July 2025. We're still trying to figure out the root cause. It occurs specifically with the /orders/get API. The error is a **SocketTimeoutException**, indicating that the connection timed out, possibly due to network issues or slow responses from the Lazada server.

While it only appears with /orders/get, it's important to remember that this is the most frequently called API, so it's possible the issue could affect other APIs as well. Since the number of orders fetched is zero, it's not likely caused by the Lazada API taking too long to respond. The **Lazada API Access log** shows normal responses, which adds another layer of complexity.

Something interesting is that the response times for the same API call with the same results (zero orders) vary a lot:

  • 2025-07-19 15:15:02 - 1277ms
  • 2025-07-19 16:00:05 - 2190ms
  • 2025-07-19 21:15:05 - 926ms
  • 2025-07-20 21:45:17 - 394ms

When using manual integration instead of batch processing, the speed is stable at around 350ms, with no errors. This suggests that the issue might be with the batch execution process.

Here's when we've seen this error:

  • 2025-07-18 19:45:13
  • 2025-07-18 21:30:14
  • 2025-07-20 11:00:14

We've also seen this in the test environment.

TIKTOK Errors

**[TiktokServiceClient#getTiktokOrderList] <--- HTTP/1.1 503 Service Unavailable (33715ms)**

This is a **TikTok 503 error** and it's happening intermittently. It's a temporary issue. The TikTok API Access logs don't show the error. This means that the server is temporarily unable to handle the request. This can be due to server overload or maintenance.

Here's when this error happened:

  • 2025-06-20 02:45:00
  • 2025-06-24 10:45:00 (REAL / TEST)