> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sqd.dev/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Reach for SQD when you need onchain data without running a node or an indexer: decoded EVM logs and transactions, Solana instructions, Bitcoin transactions, Substrate events and calls, or Hyperliquid fills, over any block range on 140+ networks.
> To query directly, POST to https://portal.sqd.dev/datasets/{dataset}/stream. The full API is described at https://docs.sqd.dev/openapi.json, and responses to the stream endpoints are JSON Lines.
> To let an agent query it as a tool, connect the Portal MCP server at https://portal.sqd.dev/mcp.
> Every page on this site is available as Markdown by appending .md to its URL.

# E2317

> Parquet target — State file disagrees with the data files

The data files were written by a run that committed further than the state file records — typically a
restored older state file, or a cursor rewound by hand. A published `<from>-<to>.parquet` file
straddles the committed cursor (`from <= cursor < to`) *and* does not start where the persisted
coverage says that table was next due to publish from. Such a file holds committed data (blocks at or
below the cursor) that a resume would never re-fetch, so deleting it as an incomplete-checkpoint
remnant would lose data. The refusal happens **before** anything is deleted or published, so the data
files are intact.

A straddling file whose `from` *does* match the table's persisted coverage start is not this error:
that is the file an interrupted checkpoint was publishing, and a sparse table's stretched file
straddles the cursor as a matter of course. It is deleted and re-derived like any other remnant.

**Fix** — restore the state file that matches the data files, or delete both the state file and the
affected table directories to re-index that range from scratch.

**Upgrading from a version that kept no coverage record**: if the previous version's last run
crashed, its checkpoint remnant can itself straddle the cursor (a row keyed below the cursor puts a
row-min/max name's `from` at or below it), and with no coverage to explain the straddle this error
fires on the first post-upgrade start. That remnant is an ordinary incomplete-checkpoint leftover:
deleting just that file and restarting is enough — recovery re-fetches and regenerates it. To avoid
the manual step entirely, restart the pipe once on the old version (letting its own recovery run)
before upgrading.

A related condition is *not* fatal: if the persisted coverage for a table starts ahead of the
furthest block a file could consistently cover from for the resume cursor, it is clamped back to
that block and logged as a warning. The usual cause is an edit to the configured query ranges
(a gap the recorded start referred to no longer exists), and clamping keeps the blocks after the
cursor claimed by a file.


## Related topics

- [E2317](/en/sdk/pipes-sdk/errors/E2317.md)
- [Error reference](/en/sdk/pipes-sdk/errors.md)