You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Pick some file that can be successfully processed.
Adjust the environment, so that the file succeeds on the last try. (Trivial way: set retries = 0)
Upload the file.
Expected results
The job is successful and the item is created.
Actual results
The job is successful, but the item isn't visible. When I look into the DB, the item is still in processing state.
Analysis
IIUC, in case of isLastRetry, the job is processed in slightly different way.
a. When some retries are remaining, the item state is updated (.flatMap(itemStateTask(store, ItemState.Created)))
b. When no retry is remaining and the job fails, the state is also updates (.flatMap(_ => itemStateTask(store, ItemState.Created)(data)))
c. When no retry is remaining and the job succeeds, I don't see such code.
In my case, I had retries=0, because it creates more readable logs (exceptions aren't repeated for each attempt). With retries>0, you usually don't hit the bug, as most jobs probably either succeed at the first attempt or fail on all attempts.
The text was updated successfully, but these errors were encountered:
v6ak
changed the title
Jobs that suceed on the last try create items stuck at `
Jobs that suceed on the last try create items stuck at processing state
Jan 27, 2024
Steps:
retries = 0
)Expected results
The job is successful and the item is created.
Actual results
The job is successful, but the item isn't visible. When I look into the DB, the item is still in
processing
state.Analysis
IIUC, in case of isLastRetry, the job is processed in slightly different way.
a. When some retries are remaining, the item state is updated (
.flatMap(itemStateTask(store, ItemState.Created))
)b. When no retry is remaining and the job fails, the state is also updates (
.flatMap(_ => itemStateTask(store, ItemState.Created)(data))
)c. When no retry is remaining and the job succeeds, I don't see such code.
In my case, I had
retries=0
, because it creates more readable logs (exceptions aren't repeated for each attempt). With retries>0, you usually don't hit the bug, as most jobs probably either succeed at the first attempt or fail on all attempts.The text was updated successfully, but these errors were encountered: