Pumpkin-MC/Pumpkin · warning · TelemetryVerificationError
Invalid timestamp string format
Error message
Invalid timestamp string format
What it means
TelemetryVerificationError::InvalidTimestamp is returned during telemetry request signature verification when the timestamp string extracted from the request cannot be parsed into a valid timestamp. Signature verification requires a well-formed timestamp to bind the request to a point in time before checking drift and signature; a malformed string fails fast with this error.
Solutions
- Send the timestamp in the exact format the verifier expects (check the client implementation for the canonical format, e.g. RFC 3339 or epoch string)
- Update/upgrade the telemetry client library so it produces the current timestamp format
- Inspect the raw request (proxy logs) to confirm the timestamp field is not stripped or rewritten in transit
- If testing manually, generate the timestamp programmatically rather than typing it
Example fix
// before
headers.insert("x-timestamp", "09/09/2026 12:00");
// after
headers.insert("x-timestamp", &chrono::Utc::now().to_rfc3339()); Defensive patterns
Strategy: validation
Validate before calling
fn valid_timestamp(ts: &str) -> bool {
chrono::DateTime::parse_from_rfc3339(ts).is_ok()
}
// call before signing/sending: assert!(valid_timestamp(&ts)) Try / catch
match verify_signature(&req) {
Err(TelemetryVerificationError::InvalidTimestamp) => {
reject(400, "timestamp must be RFC 3339");
}
other => other?,
} Prevention
- Always generate timestamps with a standard library formatter (RFC 3339)
- Never hand-type timestamps in test requests
- Check proxies/gateways don't rewrite the timestamp header
- Keep client telemetry libraries up to date with the server's expected format
When it happens
Trigger: A telemetry client sends a request whose timestamp header/field is absent-of-format — wrong date format, empty string, non-numeric epoch, or a string with unexpected characters — and verification attempts to parse it.
Common situations: Client and server agreeing on different timestamp formats after an API change; manually crafted or replayed requests with hand-written timestamps; a proxy stripping or rewriting the timestamp header; misconfigured custom telemetry clients.
Related errors
- Timestamp drift exceeded: drift was
- Could not parse UUID from validated token
- Failed to verify Ed25519 signature
- Invalid public key hex encoding
- Invalid public key bytes
AI-assisted analysis of Pumpkin-MC/Pumpkin@8d4639e25a (2026-09-09).
Data as JSON: /api/errors/090b377b7e3fb54a.
Report an issue: GitHub.
Appendix: source
Thrown at crates/pumpkin/src/telemetry.rs:121
/// Signs telemetry message data using an Ed25519 signing key and returns `(public_key_hex, signature_hex)`.
#[must_use]
pub fn sign_telemetry_payload(
signing_key: &SigningKey,
timestamp_str: &str,
body_bytes: &[u8],
) -> (String, String) {
let signed_data = compute_signed_data(timestamp_str, body_bytes);
let signature = signing_key.sign(&signed_data);
let pubkey_hex = hex::encode(signing_key.verifying_key().to_bytes());
let sig_hex = hex::encode(signature.to_bytes());
(pubkey_hex, sig_hex)
}
/// Errors that can occur during telemetry request signature verification.
#[derive(Debug, thiserror::Error, PartialEq, Eq)]
pub enum TelemetryVerificationError {
#[error("Invalid timestamp string format")]
InvalidTimestamp,
#[error(
"Timestamp drift exceeded: drift was {drift}s (max allowed is {MAX_CLOCK_DRIFT_SECS}s)"
)]
ClockDriftExceeded { drift: u64 },
#[error("Invalid public key hex encoding")]
InvalidPublicKeyHex,
#[error("Invalid public key bytes: {0}")]
InvalidPublicKey(String),
#[error("Invalid signature hex encoding")]
InvalidSignatureHex,
#[error("Invalid signature bytes: {0}")]
InvalidSignature(String),
#[error("Signature verification failed: {0}")]
VerificationFailed(String),
}
/// Verifies a signed telemetry request against an Ed25519 public key and timestamp.View on GitHub (pinned to 8d4639e25a)