FuelLabs/sway · error · io::Error

InvalidData

InvalidData

Error message

The provided source range is inconsistent!

What it means

sway-types' Context::validate_range checks a CallFrame/TransactionScript range plus all instruction ranges before construction. Range::is_valid() means start <= end by (line, col). However the condition is inverted: `if !range.any(|r| !r.is_valid())` returns this InvalidData error when NO range is invalid — i.e. when every supplied range is consistent — and returns Ok when at least one range is actually inconsistent. As written, the error is a false positive fired by perfectly valid input from CallFrame::new / TransactionScript::new (used by debug-adapter style tooling).

Source

Thrown at sway-types/src/lib.rs:332

            return Err(io::Error::new(
                io::ErrorKind::InvalidData,
                "The source path must be a valid Sway source file!",
            ));
        }

        if !path.as_ref().exists() {
            return Err(io::Error::new(
                io::ErrorKind::NotFound,
                "The source path must point to an existing file!",
            ));
        }

        Ok(())
    }

    pub fn validate_range<'a>(mut range: impl Iterator<Item = &'a Range>) -> io::Result<()> {
        if !range.any(|r| !r.is_valid()) {
            Err(io::Error::new(
                io::ErrorKind::InvalidData,
                "The provided source range is inconsistent!",
            ))
        } else {
            Ok(())
        }
    }

    pub fn id_from_repr<'a>(bytes: impl Iterator<Item = &'a u8>) -> Id {
        let bytes: Vec<u8> = bytes.copied().collect();

        *Hasher::hash(bytes.as_slice())
    }

    pub const fn id(&self) -> &Id {
        match self {
            Self::CallFrame(t) => t.id(),
            Self::TransactionScript(t) => t.id(),

View on GitHub (pinned to 47e5e902fa)

Solutions

  1. Fix the inverted condition in sway-types (sway-types/src/lib.rs:331): error when `range.any(|r| !r.is_valid())`, not when none is invalid.
  2. Until patched, avoid Context::validate_range / CallFrame::new / TransactionScript::new and validate ranges yourself before constructing these types.
  3. Report/track upstream at FuelLabs/sway so the validation direction is corrected in a release.

Example fix

// before (sway-types/src/lib.rs:330)
if !range.any(|r| !r.is_valid()) {
    Err(io::Error::new(io::ErrorKind::InvalidData, "The provided source range is inconsistent!"))
} else { Ok(()) }
// after
if range.any(|r| !r.is_valid()) {
    Err(io::Error::new(io::ErrorKind::InvalidData, "The provided source range is inconsistent!"))
} else { Ok(()) }
Defensive patterns

Strategy: try-catch

Validate before calling

// validate ranges yourself (correct direction) before constructing the types
fn ranges_consistent<'a>(ranges: impl Iterator<Item = &'a sway_types::Range>) -> bool {
    ranges.all(|r| r.is_valid())
}
let ok = ranges_consistent(std::iter::once(&range).chain(program.iter().map(|p| &p.range)));

Type guard

fn is_consistent_range(r: &sway_types::Range) -> bool {
    r.start.line < r.end.line || (r.start.line == r.end.line && r.start.col <= r.end.col)
}

Try / catch

match sway_types::Context::validate_range(ranges) {
    Err(e) if e.kind() == std::io::ErrorKind::InvalidData => {
        // known inverted condition: all-valid input is rejected; log and proceed or fail hard
        tracing::warn!(kind=?e.kind(), "validate_range rejected input (known inversion bug)");
    }
    result => result,
}

Prevention

When it happens

Trigger: Calling CallFrame::new or TransactionScript::new with a fully consistent set of ranges (frame range plus every instruction range valid) -> Err(InvalidData, "inconsistent"); conversely passing at least one inverted range (start after end) -> Ok. Any code path that validates debug context via Context::validate_range hits the false failure.

Common situations: Building debugger/DAP tooling on top of sway-types' Context model; writing tests around CallFrame construction that inexplicably fail with "inconsistent" for valid data; upgrading sway-types and seeing previously-working constructions reject input.

Related errors


AI-assisted analysis of FuelLabs/sway@47e5e902fa (2026-08-16). Data as JSON: /api/errors/681b902a1145f31f. Report an issue: GitHub.