Documentation

Troubleshoot issues writing data

Learn how to avoid unexpected results and recover from errors when writing to InfluxDB Cloud Serverless.

Handle write responses

InfluxDB Cloud Serverless does the following when you send a write request:

  1. Validates the request.

  2. If successful, attempts to ingest data from the request body; otherwise, responds with an error status.

  3. Ingests or rejects data from the batch and returns one of the following HTTP status codes:

    • 204 No Content: All of the data is ingested and queryable.
    • 400 Bad Request: Some or all of the data has been rejected. Data that has not been rejected is ingested and queryable.

    The response body contains error details about rejected points, up to 100 points.

Writes are synchronous–the response status indicates the final status of the write and all ingested data is queryable.

To ensure that InfluxDB handles writes in the order you request them, wait for the response before you send the next request.

Review HTTP status codes

InfluxDB uses conventional HTTP status codes to indicate the success or failure of a request. The message property of the response body may contain additional details about the error. InfluxDB Cloud Serverless returns one the following HTTP status codes for a write request:

HTTP response codeResponse bodyDescription
204 "No Content"no response bodyIf InfluxDB ingested all of the data in the batch
400 "Bad request"error details about rejected points, up to 100 points: line contains the first rejected line, message describes rejectionsIf some or all request data isn’t allowed (for example, is malformed or falls outside of the bucket’s retention period)–the response body indicates whether a partial write has occurred or if all data has been rejected
401 "Unauthorized"If the Authorization header is missing or malformed or if the token doesn’t have permission to write to the bucket. See examples using credentials in write requests.
404 "Not found"requested resource type (for example, “organization” or “bucket”), and resource nameIf a requested resource (for example, organization or bucket) wasn’t found
413 “Request too large”cannot read data: points in batch is too largeIf a request exceeds the maximum global limit
429 “Too many requests”If the number of requests exceeds the adjustable service quota. The Retry-After header contains the number of seconds to wait before trying the write again.
500 "Internal server error"Default status for an error
503 "Service unavailable"If the server is temporarily unavailable to accept writes. The Retry-After header contains the number of seconds to wait before trying the write again.

The message property of the response body may contain additional details about the error. If your data did not write to the bucket, see how to troubleshoot rejected points.

Troubleshoot failures

If you notice data is missing in your database, do the following:

Troubleshoot rejected points

When writing points from a batch, InfluxDB rejects points that have syntax errors or schema conflicts. If InfluxDB processes the data in your batch and then rejects points, the HTTP response body contains the following properties that describe rejected points:

  • code: "invalid"
  • line: the line number of the first rejected point in the batch.
  • message: a string that contains line-separated error messages, one message for each rejected point in the batch, up to 100 rejected points.

InfluxDB rejects points for the following reasons:

  • a line protocol parsing error
  • an invalid timestamp
  • a schema conflict

Schema conflicts occur when you try to write data that contains any of the following:

  • a wrong data type: the point falls within the same partition (default partitioning is measurement and day) as existing bucket data and contains a different data type for an existing field
  • a tag and a field that use the same key

Example

The following example shows a response body for a write request that contains two rejected points:

{
  "code": "invalid",
  "line": 2,
  "message": "failed to parse line protocol:
              errors encountered on line(s):
              error parsing line 2 (1-based): Invalid measurement was provided
              error parsing line 4 (1-based): Unable to parse timestamp value '123461000000000000000000000000'"
}

Check for field data type differences between the rejected data point and points within the same database and partition–for example, did you attempt to write string data to an int field?


Was this page helpful?

Thank you for your feedback!


The future of Flux

Flux is going into maintenance mode. You can continue using it as you currently are without any changes to your code.

Read more

InfluxDB v3 enhancements and InfluxDB Clustered is now generally available

New capabilities, including faster query performance and management tooling advance the InfluxDB v3 product line. InfluxDB Clustered is now generally available.

InfluxDB v3 performance and features

The InfluxDB v3 product line has seen significant enhancements in query performance and has made new management tooling available. These enhancements include an operational dashboard to monitor the health of your InfluxDB cluster, single sign-on (SSO) support in InfluxDB Cloud Dedicated, and new management APIs for tokens and databases.

Learn about the new v3 enhancements


InfluxDB Clustered general availability

InfluxDB Clustered is now generally available and gives you the power of InfluxDB v3 in your self-managed stack.

Talk to us about InfluxDB Clustered

InfluxDB Cloud Serverless