[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-08-08 UTC。"],[],[],null,["# Spanner error codes\n\nThis page describes Spanner error codes and recommended actions to\nhandle these errors. Google APIs, including Spanner, use the\ncanonical error codes defined by [`google.rpc.Code`](https://github.com/googleapis/googleapis/blob/master/google/rpc/code.proto).\n\nWhen a Spanner request is successful, the API returns an HTTP\n`200 OK` status code along with the requested data in the body of the response.\n\nWhen a request fails, the Spanner API returns an HTTP\n`4xx` or `5xx` status code that generically identifies the failure as well as a\nresponse that provides more specific information about the error(s) that caused\nthe failure.\n\nThe response object contains a single field `error` whose value contains the\nfollowing elements:\n\nIf a request made with a content type of `application/x-protobuf` results in an\nerror, it will return a serialized [`google.rpc.Status`](https://github.com/googleapis/googleapis/blob/master/google/rpc/status.proto) message as the\npayload.\n| **Note:** The text provided in the message might change at any time so applications shouldn't depend on the actual text.\n\nError codes\n-----------\n\nThe recommended way to classify errors is to inspect the value of the\n[canonical error code](https://github.com/googleapis/googleapis/blob/master/google/rpc/code.proto) (`google.rpc.Code`). In JSON errors, this code appears\nin the `status` field. In `application/x-protobuf` errors, it's in the `code`\nfield.\n\n### Session errors\n\nSpanner uses [sessions](/spanner/docs/sessions) to manage\ninteractions between your application and the database. Sessions represent a\nconnection to the database and facilitate operations like reads and writes.\n\nCommon session-related errors that your application might encounter\ninclude:\n\n- [`Session not found`](#session-not-found)\n- [`RESOURCE_EXHAUSTED`](#session-resource-exhausted)\n\n#### Session not found\n\nThe `Session not found` error occurs when your application attempts to use a\nsession that no longer exists. This can happen for several reasons.\n\n- Your client application might explicitly delete a session. For example,\n closing a database client in your code or calling the `deleteSessions` API\n directly removes the session. If you don't use one of the\n Spanner client libraries, create a new session when this error\n occurs. Add the new session to your session pool and remove the deleted\n session from the pool.\n\n- Spanner also automatically deletes sessions under certain\n conditions.\n\n - It deletes a session if it remains idle for more than one hour. This can\n occur in data stream jobs where downstream processing takes longer than the\n session idle timeout. If you're using a Dataflow job, add a\n `Reshuffle` transform operation after the Spanner read in the\n Dataflow pipeline. This can help decouple the\n Spanner read operation from the subsequent long-running\n processing steps.\n\n - Spanner also deletes a session if it is older than 28 days.\n If you're using the client library, it handles these cases automatically. If\n you don't use one of the Spanner client libraries, create a\n new session when this error occurs. Add the new session to your session pool\n and remove the deleted session from the pool.\n\n- If you use one of the [Spanner client libraries](/spanner/docs/reference/libraries),\n then the library manages sessions automatically. If you encounter this error,\n verify that your code doesn't explicitly delete sessions, such as by closing\n the database client. Occasionally, this might also be caused by an issue in\n the client library's session management.\n\n#### Resource exhausted\n\nThe `RESOURCE_EXHAUSTED: No session available in the pool` or\n`RESOURCE_EXHAUSTED: Timed out after waiting `\u003cvar translate=\"no\"\u003eX\u003c/var\u003e` ms for acquiring session`\nerrors indicate that your application can't acquire a session from the session\npool. This happens when no sessions are available to process new read or write\nrequests.\n\nThe following table describes some reasons that might cause these errors, and\ncorresponding recommended actions.\n\n### Flow control mechanism errors\n\nSpanner might activate its flow control mechanism to protect\nitself from overload under the following conditions:\n\n- There is high CPU usage on the Spanner node. If you suspect that your request is causing high CPU usage, then you can use the [CPU utilization metrics](/spanner/docs/cpu-utilization) to investigate the issue.\n- There might be hotspots, which increase the processing time of the request. If you suspect that your request is causing hotspots, refer to [Find hotspots in your database](/spanner/docs/find-hotspots-in-database) to investigate the issue. For more information, see [Key Visualizer](/spanner/docs/key-visualizer).\n\nThe flow control mechanism is supported by the following client libraries:\n\n- [Go Client v1.65 or later](https://github.com/googleapis/google-cloud-go/releases/tag/spanner%2Fv1.65.0)\n- [Java Client v6.72 or later](https://github.com/googleapis/java-spanner/releases/tag/v6.72.0)\n\nThe overall time for the request to complete won't increase due to the use of\nthe flow control mechanism. Without this mechanism, Spanner waits\nbefore processing the request and eventually returns a `DEADLINE_EXCEEDED`\nerror.\n\nWhen the flow control mechanism is active, Spanner pushes\nrequests back to the client to retry. If the retry consumes the entire\nuser-provided deadline, then the client receives a `RESOURCE_EXHAUSTED` error.\nThis error is returned if Spanner estimates that the processing\ntime of the request is too long. The error propagates flow control and\nSpanner retries the request to the client, instead of\naccumulating retries internally. This allows Spanner to avoid\naccumulating additional resource consumption."]]
