nautechsystems/nautilus_trader · error
Missing {description} address in topic{topic_index} when par
Error message
Missing {description} address in topic{topic_index} when parsing event What it means
extract_address_from_topic pulls an Address out of a hypersync log's topics array at a given index. Event topics are optional (a topic slot may be absent or None), but the caller requires the address at that position — so when the topic is missing, the function bails with this message naming the description (e.g. which address) and the topic index.
Source
Thrown at crates/adapters/blockchain/src/hypersync/log.rs:35
use nautilus_core::hex;
use super::HypersyncLog;
use crate::exchanges::parsing::core;
/// Extracts an address from a specific topic in a log entry
///
/// # Errors
///
/// Returns an error if the topic at the specified index is not present in the log.
pub fn extract_address_from_topic(
log: &HypersyncLog,
topic_index: usize,
description: &str,
) -> anyhow::Result<Address> {
match log.topics.get(topic_index).and_then(|t| t.as_ref()) {
Some(topic) => core::extract_address_from_bytes(topic.as_ref()),
None => {
anyhow::bail!("Missing {description} address in topic{topic_index} when parsing event")
}
}
}
/// Extracts the transaction hash from a log entry
///
/// # Errors
///
/// Returns an error if the transaction hash is not present in the log.
pub fn extract_transaction_hash(log: &HypersyncLog) -> anyhow::Result<String> {
log.transaction_hash
.as_ref()
.map(ToString::to_string)
.ok_or_else(|| anyhow::anyhow!("Missing transaction hash in log"))
}
/// Extracts the transaction index from a log entry
///View on GitHub (pinned to 18893faf8b)
Solutions
- Verify the event ABI: confirm the event at topic0 actually has an indexed parameter at the requested topic index before extracting.
- Check topics.len() and topics[i].is_some() before calling, or handle the error as 'not this event' and skip the log.
- Ensure the log filter/query targets the correct event signature so topic layout matches expectations.
- If the event legitimately has optional topics, use an overload/fallback that treats a missing topic as absent instead of an error.
Example fix
// before
let from = extract_address_from_topic(&log, 1, "sender")?; // panics into bail if topics[1] absent
// after
if log.topics.get(1).and_then(|t| t.as_ref()).is_some() {
let from = extract_address_from_topic(&log, 1, "sender")?;
} else {
return Ok(None); // not the expected event layout
} Defensive patterns
Strategy: validation
Validate before calling
fn topic_present(log: &Log, idx: usize) -> bool {
log.topics.get(idx).and_then(|t| t.as_ref()).is_some()
}
// only extract when topic_present(&log, topic_index) Type guard
fn topic_at<'a>(log: &'a Log, idx: usize) -> Option<&'a [u8]> {
log.topics.get(idx).and_then(|t| t.as_ref()).map(|t| t.as_ref())
} Try / catch
match extract_address_from_topic(&log, 1, "sender") {
Err(e) if e.to_string().starts_with("Missing ") => /* treat as non-matching event, skip log */,
Err(e) => return Err(e),
Ok(addr) => addr,
} Prevention
- Match logs against the exact event signature (topic0) before reading indexed topics
- Keep topic-index constants in one place tied to the event ABI definition
- Filter hypersync queries by event signature so logs have the expected topic layout
- Handle optional/anonymous events explicitly rather than assuming ERC-20-style topic layout
When it happens
Trigger: Calling extract_address_from_topic(log, topic_index, description) where log.topics has fewer entries than topic_index+1 or topics[topic_index] is None — typically extracting a sender/recipient address from topic1/topic2/topic3 of an event whose actual signature has fewer indexed parameters.
Common situations: Decoding logs with the wrong event ABI (topic index beyond the event's indexed params); anonymous events or events with optional indexed fields; filtering hypersync logs whose signatures differ from the assumed ERC-20-style Transfer(topic0, from topic1, to topic2); malformed/partial log data from the provider.
Understand the failure class
Background: "missing required argument" and "the following required arguments were not provided": what required-argument errors mean and how to fix them — this error's family across 20 libraries.
Related errors
- HyperSync parsing of burn event is not defined in this dex:
- HyperSync parsing of initialize event is not defined in this
- HyperSync parsing of collect event is not defined in this de
- HyperSync parsing of flash event is not defined in this dex:
- HyperSync parsing of SetFeeProtocol event is not defined in
AI-assisted analysis of nautechsystems/nautilus_trader@18893faf8b (2026-09-08).
Data as JSON: /api/errors/e91126ba92b6836f.
Report an issue: GitHub.