Common errors that occur when using Game Server Services.

GS2 responds to errors according to certain rules. By understanding these rules, you will be able to resolve errors quickly.

Example of an error message

[{"component": "progress", "message": "quest.progress.progress.error.notFound"}]
componentIndicates the target where the error occurred, and contains the member name and method name.
messageDetails of the error location and keywords that describe the error. serviceName.component.error.errorType

Major error types

major error contentdescription
failedProcessing failed.
invalidIllegal parameter.
requireMissing required argument.
tooLongArgument is too long.
tooManyToo many array elements.
existsAlready exists.
duplicateduplicate, already exists.
notFoundNot found.
notMatchNo match was found.

Types of Exceptions

Errors are classified to some extent by SDK, and the type of exception sent out varies.

ExceptionError ContentStatus CodeRetry recommended
BadRequestExceptionBad request content.400
UnauthorizedExceptionCould not authenticate the authorization required to connect to GS2; also raised if the access token used for API access has expired.401
QuotaLimitExceededExceptionQuota (allocation) limit exceeded.402
NotFoundExceptionThe object of the request could not be found.404
ConflictExceptionProcessing conflict.409
InternalServerErrorExceptionAn error occurred on the server.500
BadGatewayExceptionThe server received an invalid response. This error occurs when a connection with another server or GS2 microservice fails.502
ServiceUnavailableExceptionAn error occurred in the service.503
RequestTimeoutExceptionRequest timed out.504
UnknownExceptionUnknown exception occurred.505

Exceptions marked “Retry recommended” are errors that may occur due to server conditions, although the request parameters are normal. When such errors are detected, it is recommended to retry.

It is strongly recommended to implement a timeout after a certain number of times or a certain amount of time, rather than retrying until success. When retrying, it is recommended that a sleep be inserted between requests, and that the length of the sleep be increased according to the number of retries.

For errors that require in-game handling, some microservices define error-specific exception types that inherit from the exceptions enumerated for each microservice. In such cases, error handling can be more easily implemented by using error-specific exceptions. If there are exceptions that represent error-specific errors, please refer to the method descriptions in the API reference.