Skip to content

Make result iteration recoverable from errors#615

Merged
hashhar merged 1 commit into
trinodb:masterfrom
hashhar:hashhar/fix-iterator
Jul 8, 2026
Merged

Make result iteration recoverable from errors#615
hashhar merged 1 commit into
trinodb:masterfrom
hashhar:hashhar/fix-iterator

Conversation

@hashhar

@hashhar hashhar commented Jul 7, 2026

Copy link
Copy Markdown
Member

Description

TrinoResult implemented iteration as a generator. A generator that raises an unhandled exception is finalized so every subsequent next() raises StopIteration which dbapi's fetchone() maps to None. Since spooled segments are downloaded lazily during iteration, a transient error (e.g. an S3 timeout) mid-iteration permanently killed the iterator and silently dropped the remaining rows as if the query had completed normally.

Rewrite TrinoResult as a class-based iterator that keeps its state on the instance. An error propagates to the caller while the iterator stays usable, so a persistent error keeps surfacing instead of turning into StopIteration and a retried next() resumes where the failure happened.

Also make SegmentIterator retry-safe. Acknowledge and advance past a segment only after it was decoded successfully so retrying after a failed segment download re-decodes the same segment instead of acknowledging and skipping it.

Non-technical explanation

Release notes

( ) This is not user-visible or docs only and no release notes are required.
( ) Release notes are required, please propose a release note for me.
( ) Release notes are required, with the following suggested text:

* Fix some things. ({issue}`issuenumber`)

Fixes #598.

@cla-bot cla-bot Bot added the cla-signed label Jul 7, 2026
@hashhar hashhar requested a review from azawlocki-sbdt July 7, 2026 15:48
@hashhar hashhar marked this pull request as ready for review July 7, 2026 15:48
@hashhar hashhar force-pushed the hashhar/fix-iterator branch from db1a3b8 to 80fbe0c Compare July 7, 2026 15:48

@azawlocki-sbdt azawlocki-sbdt left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, code comments make it a good read. My only suggestion would be to cover more scenarios in tests, but it's non-blocking.

Comment thread tests/unit/test_client.py Outdated
Comment thread tests/unit/test_client_spooling.py Outdated
Comment thread trino/client.py
TrinoResult implemented iteration as a generator. A generator that
raises an unhandled exception is finalized so every subsequent next()
raises StopIteration which dbapi's fetchone() maps to None. Since
spooled segments are downloaded lazily during iteration, a transient
error (e.g. an S3 timeout) mid-iteration permanently killed the iterator
and silently dropped the remaining rows as if the query had completed
normally.

Rewrite TrinoResult as a class-based iterator that keeps its state on
the instance. An error propagates to the caller while the iterator stays
usable, so a persistent error keeps surfacing instead of turning into
StopIteration and a retried next() resumes where the failure happened.

Also make SegmentIterator retry-safe. Acknowledge and advance past a
segment only after it was decoded successfully so retrying after a
failed segment download re-decodes the same segment instead of
acknowledging and skipping it.
@hashhar hashhar force-pushed the hashhar/fix-iterator branch from 80fbe0c to f4e7888 Compare July 8, 2026 22:02
@hashhar hashhar merged commit 0893cfe into trinodb:master Jul 8, 2026
11 checks passed
@hashhar hashhar deleted the hashhar/fix-iterator branch July 8, 2026 22:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Development

Successfully merging this pull request may close these issues.

TrinoResult generator cannot recover from errors during lazy segment iteration

2 participants