Fix task failure signal race condition#15917
Conversation
8236bff to
3f089a8
Compare
e9d656f to
b707a8f
Compare
core/trino-main/src/main/java/io/trino/execution/SqlTaskManager.java
Outdated
Show resolved
Hide resolved
b707a8f to
6693557
Compare
core/trino-main/src/main/java/io/trino/server/TaskResource.java
Outdated
Show resolved
Hide resolved
core/trino-main/src/main/java/io/trino/server/TaskResource.java
Outdated
Show resolved
Hide resolved
core/trino-main/src/main/java/io/trino/server/TaskResource.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
nit: move to a separate commit
There was a problem hiding this comment.
Actually, this is all related code. The movement to here alone would cause issues with scheduleDriversWithTaskLifecycle() not being called when taskHandle == null. This is "fine" because it doesn't break the task state machine model today, but causes problems in a world with terminating task states.
core/trino-main/src/main/java/io/trino/execution/buffer/LazyOutputBuffer.java
Outdated
Show resolved
Hide resolved
6693557 to
4beeb65
Compare
There was a problem hiding this comment.
The assumption is that sending emptyResults(taskInstanceId, 0, completed: false) is safe, even though the previous comment suggested otherwise, because TaskResource will respond similarly when the timeout threshold is reached. Sending these responses instead of letting them time out should propagate task failure information more quickly than allowing the timeout to expire.
3fb5438 to
221d471
Compare
953a388 to
31684aa
Compare
Previously, SqlTaskExecution registered an outputBuffer callback for CheckTaskCompletionOnBufferFinish in the constructor, which published a reference to "this" that could become visible to another thread in an unsafe way. This callback was moved to the start() method instead. SqlTask is also reordered to call SqlTaskExecution#start() before publishing a reference to it via the TaskHolder reference, which was unsafe under concurrent state machine activity on another thread. Instead, taskHolderReference updates must now synchronize on a single taskHolderLock before mutating the holder reference.
Sends responses eagerly to pending readers in LazyOutputBuffer when a task aborts the output buffer.
31684aa to
465d500
Compare
465d500 to
93e5561
Compare
Description
Fixes the sequence of operations around
TaskResourcechecking for task failure until after the buffer response future is completed. Otherwise, tasks could inappropriately announce completion rather than failure to consumers which can yield incorrect query results.Additional context and related issues
Discovered while attempting to debug a swath of test failures producing incorrect results in #15478 which made the sequence of interleaving operations necessary to trigger the correctness bug more likely to occur.
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.
(x) Release notes are required, with the following suggested text: