influxdata/influxdb · error · V1WriteParseError::DecodeFail

failed to deserialize db/rp/precision in request

Error message

failed to deserialize db/rp/precision in request: {0}

What it means

V1WriteParseError::DecodeFail wraps serde_urlencoded/serde deserialization failures when parsing the db/rp/precision parameters of a v1 write request. It is raised when the parameters are present but malformed (bad format, wrong types, invalid encoding). The source serde error is embedded in the message via {0}.

Solutions

  1. Read the inner serde error in the message to identify which parameter failed to decode.
  2. Use only accepted precision values: ns, u (or us), ms, s.
  3. Percent-encode db/rp values containing special characters.
  4. Match on V1WriteParseError::DecodeFail(_) to surface a 400 with the underlying decode message.

Example fix

// before
POST /write?db=mydb&precision=seconds
// after
POST /write?db=mydb&precision=s
Defensive patterns

Strategy: try-catch

Validate before calling

const PRECISIONS: [&str; 4] = ["ns", "u", "ms", "s"];
if let Some(p) = precision {
    assert!(PRECISIONS.contains(&p), "invalid precision: {p}");
}

Try / catch

match err {
    V1WriteParseError::DecodeFail(e) => /* 400 with e.to_string() */,
    other => /* propagate */,
}

Prevention

When it happens

Trigger: Sending /write?db=... with a precision value not in the accepted set (s, ms, u/us, ns), or query strings that fail serde_urlencoded deserialization (bad percent-encoding, duplicate malformed keys).

Common situations: Typo in precision (e.g. precision=seconds); unescaped special characters in db names; clients writing integer precision codes from other APIs.

Understand the failure class

Background: "Invalid ... format", "must be in format X", "does not look like a ..." — invalid argument format errors across CLI tools and libraries — this error's family across 17 libraries.

Related errors


AI-assisted analysis of influxdata/influxdb@06200ef96b (2026-09-19). Data as JSON: /api/errors/ae9f1c013850be3c. Report an issue: GitHub.

Appendix: source

Thrown at core/iox_http/src/write/v1.rs:24

use iox_http_util::Request;
use serde::{Deserialize, Deserializer};

use super::Precision;

// When a retention policy is provided, it is appended to the db field,
// separated by a single `/`.
pub const V1_NAMESPACE_RP_SEPARATOR: char = '/';

/// v1 DmlErrors returned when decoding the database / rp information from a
/// HTTP request and deriving the namespace name from it.
#[derive(Debug, thiserror::Error)]
pub enum V1WriteParseError {
    /// The request contains no db destination information.
    #[error("no db destination provided")]
    NoQueryParams,

    /// The request contains invalid parameters.
    #[error("failed to deserialize db/rp/precision in request: {0}")]
    DecodeFail(#[from] serde::de::value::Error),
}

/// May be empty string, explicit rp name, or `autogen`. As provided at the
/// write API. Handling is described in context of the construction of the
/// `NamespaceName`, and not an explicit honouring for retention duration.
#[derive(Debug, Default)]
pub enum RetentionPolicy {
    /// The user did not specify a retention policy (at the write API).
    #[default]
    Unspecified,
    /// Default on v1 database creation, if no rp was provided.
    Autogen,
    /// The user specified the name of the retention policy to be used.
    Named(String),
}

impl<'de> Deserialize<'de> for RetentionPolicy {

View on GitHub (pinned to 06200ef96b)