Skip to content

Conversation

@etiennebarrie
Copy link
Member

If a job starts without a cursor (i.e. after a run is resumed), but the run has a cursor, we do use the cursor from the run in build_enumerator.

However, we don't store the cursor on the job itself at this point. If the first iteration fails, we go through the on_error callback and store the job cursor, which is nil, on the run, effectively losing the progress previously made on the run.

This fixes this issue by always storing the cursor on the job in build_enumerator, making sure the job and run have the same cursor.

Fixes #1033

If a job starts without a cursor (i.e. after a run is resumed), but the
run has a cursor, we do use the cursor from the run in build_enumerator.

However, we don't store the cursor on the job itself at this point. If
the first iteration fails, we go through the `on_error` callback and
store the job cursor, which is `nil`, on the run, effectively losing the
progress previously made on the run.

This fixes this issue by always storing the cursor on the job in
`build_enumerator`, making sure the job and run have the same cursor.
@etiennebarrie etiennebarrie merged commit ac3872a into main Jun 4, 2024
@etiennebarrie etiennebarrie deleted the always-store-run-cursor-in-job-cursor-position branch June 4, 2024 09:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants