BUG! io.trino.execution.NodeTaskMap$NodeTasks$TaskPartitionedSplitCountTracker for ... leaked with 1 partitioned splits.

[zhimo2022]

2022-11-21T09:30:28.276+0800 ERROR FinalizerService io.trino.execution.NodeTaskMap BUG! io.trino.execution.NodeTaskMap$NodeTasks$TaskPartitionedSplitCountTracker for 20221119_012047_01326_4cesq.1.0 leaked with 1 partitioned splits.
Cleaning up so server can continue to function.

in my environment, occur this log.
20221119_012047_01326_4cesq was executed two day ago...so we don't know the details , just one line log:
....TIMELINE: Query ::Transaction:..... elapsed 32 ms :: planning 11ms :: waiting 0ms ：： scheduling 21ms :: runing 237 ms ::finishing 0ms :: beging 2022-11-19T09:25:05.739+08:00 :: end 2022-11-19T09:25:05.771+08：00

this environment had been running for several months correctly , and no more occur this error since 11-21.
so ....why ?
i am using tag 361

[findepi]

I don't know what this means, but looks like the log message was added by @dain , so he might know

[tooptoop4]

cc @pettyjamesm

[pettyjamesm]

The log message is printed when the component that tracks how many splits are assigned to a given node (across all tasks) detects that a task that no longer exists (ie: was finished and eventually garbage collected on the coordinator) was responsible for incorrectly indicating that some splits were still running on that node. Essentially, this log line is a warning that a task failed to clear the number of running splits it had registered with the node after terminating (which would be a bug) and the consequences of that could result in that worker node being underutilized since the scheduler will think that there are more splits currently running on that node than there actually are. However, in this case we see that only a single split was incorrectly reported so the impact in your particular environment should have been negligible.

There may have been a bug as of Trino 361 in the task cleanup logic that caused this split to "leak", or this could be the result of a single-bit memory corruption anomaly where the task did successfully set it's assigned split count to zero and the counter was later corrupted such that the 0 became a 1 sometime between the task finishing and the sanity checker logic finding a non-zero value and reporting it as "leaked" by the log line.

I would be concerned if this were occurring frequently, but would probably ignore it if you only saw this issue occur once over a long period of time.