conflicting RTDS TWAP observation topic={} symbol={} timesta

Error message

conflicting RTDS TWAP observation topic={} symbol={} timestamp_ms={} prior={} received={}

What it means

The RTDS (real-time data stream) TWAP feed tracks one observation per (topic, symbol) keyed by timestamp_ms. A new observation arrived with the same timestamp as the previously stored one but a different value, which would silently overwrite or duplicate an observation; the library treats this as a data-integrity violation and aborts processing that message.

Source

Thrown at crates/adapters/polymarket/src/rtds.rs:1574

            .values()
            .map(|tracked| tracked.data_type.clone())
            .collect::<Vec<_>>();

        if data_types.is_empty() {
            return Ok(None);
        }

        if let Some(previous) = subscription.last_twap_fingerprint {
            if timestamp_ms < previous.timestamp_ms {
                return Ok(None);
            }

            if timestamp_ms == previous.timestamp_ms {
                if value == previous.value {
                    return Ok(None);
                }

                anyhow::bail!(
                    concat!(
                        "conflicting RTDS TWAP observation topic={} symbol={} ",
                        "timestamp_ms={} prior={} received={}",
                    ),
                    topic.as_str(),
                    symbol_lower,
                    previous.timestamp_ms,
                    previous.value,
                    value,
                );
            }
        }

        subscription.last_twap_fingerprint = Some(TwapReplayFingerprint {
            timestamp_ms,
            value,
        });
        Ok(Some(data_types))

View on GitHub (pinned to 18893faf8b)

Solutions

Inspect the raw RTDS frames for the topic/symbol to see whether the venue is re-publishing corrections and whether a correction channel/metadata is being dropped
Deduplicate upstream connections: ensure only one subscription per topic exists (no duplicated filters or double-subscribe)
If venue legitimately emits corrections, relax the guard to log a warning and replace prior, or key observations by (timestamp_ms, value)
Report/pin the venue feed behavior; if it is a known upstream anomaly, bump accepted timestamps or use a higher-resolution event time

Example fix

// before
if value == previous.value {
    return Ok(None);
}
anyhow::bail!("conflicting RTDS TWAP observation ... prior={} received={}", previous.value, value);
// after
if value == previous.value {
    return Ok(None);
}
tracing::warn!("RTDS TWAP correction topic={} symbol={} ts={} prior={} received={}", topic.as_str(), symbol_lower, timestamp_ms, previous.value, value);
return Ok(Some(accepted_observation));

Defensive patterns

Strategy: validation

Validate before calling

if let Some(prev) = tracker.get(&(topic, symbol)) {
    if prev.timestamp_ms == obs.timestamp_ms && prev.value != obs.value {
        // decide: drop duplicate or log correction before feeding the API
        continue;
    }
}

Prevention

Subscribe to each RTDS topic exactly once; avoid duplicated filters
Keep a (topic, symbol) -> last observation map and pre-filter conflicting duplicates
Monitor venue feed for re-published corrections

When it happens

Trigger: Two distinct TWAP values arrive on the same RTDS topic for the same symbol with an identical millisecond timestamp (duplicate/conflicting upstream event, replayed frame, or interleaved producers). Only exact duplicate values return Ok(None); value difference triggers the bail.

Common situations: Upstream RTDS re-sending a corrected observation with the same timestamp; clock granularity too coarse on the venue; two subscriptions or duplicated subscription filters delivering the same event twice through one handler.

Understand the failure class

Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.

Related errors

AI-assisted analysis of nautechsystems/nautilus_trader@18893faf8b (2026-09-08). Data as JSON: /api/errors/0756547f644ec8fb. Report an issue: GitHub.