Support `accept_partial` writes via `/api/v3/write_lp` endpoint for partial-failure resilience

Systems
1

Problem

When writing a batch of line protocol records where even a single record has a schema conflict (e.g., integer value for a column previously defined as float), the SDK throws InfluxDBApiHttpException and the entire batch is treated as failed. There is no way for the caller to know that some records in the batch were actually written successfully by the server.

Server Capability Exists But SDK Cannot Leverage It!

Reference: https://docs.influxdata.com/influxdb3/enterprise/write-data/http-api/v3-write-lp/

The InfluxDB v3 /api/v3/write_lp endpoint supports the accept_partial query parameter (default: true). When enabled, the server writes all valid lines and returns HTTP 400 with structured details identifying only the rejected lines:

{
  "error": "partial write of line protocol occurred",
  "data": [
    {
      "error_message": "invalid column type for column 'temp'...",
      "line_number": 2,
      "original_line": "..."
    }
  ]
}

Gaps in SDK

Gap 1: /api/v3/write_lp is only accessible when noSync=true

In InfluxDBClientImpl.writeData(), the endpoint selection is:

  • noSync=true → /api/v3/write_lp

  • noSync=false (default) → /api/v2/write

There is no way to use the v3 write endpoint without also opting into noSync. The /api/v2/write endpoint does not support accept_partial.

Gap 2: HTTP 400 always throws, even on partial success

In RestClient.request(), any response with status code outside 200–299 throws InfluxDBApiHttpException.

When accept_partial=true and the server returns HTTP 400, valid lines may have been written, but the SDK reports the entire operation as failed. The caller has no programmatic way to determine which lines succeeded and which failed.

Desired Outcome

SDK consumers need the ability to

  1. Use the /api/v3/write_lp endpoint with accept_partial support
  2. Programmatically distinguish between total failure and partial failure
  3. Identify which specific lines in a batch failed (line number, error message, original line)
2

Hi, following up on this request. We’re currently seeing this issue in a high-throughput use case where a single schema/data error causes the entire batch to be rejected. We then have to process the records individually to identify the bad record and send it to DLQ, which has a significant impact on throughput.

Support for accept_partial would allow the valid records to be written in bulk while identifying only the failed records, avoiding this record-by-record fallback.

Is there any update or planned support for this in the SDK? Any guidance on a recommended workaround would also be appreciated. Thanks!