PDGGK commented on PR #18196: URL: https://github.com/apache/iotdb/pull/18196#issuecomment-5035877984
Nice catch — this looks right to me. I traced the `getTimeOut()` consumers to double-check: the runtime deadline checks in `FragmentInstanceDispatcherImpl` (`currentTime - getStartTime() >= getTimeOut()`) and the fragment-timeout computations that do `getTimeOut() - (now - getStartTime())` (`SimpleFragmentParallelPlanner`, `TableModelQueryFragmentPlanner`, …) all treat `getTimeOut()` as the total duration from `getStartTime()`, so the post-planning reassignment was effectively subtracting the planning time twice. Removing it restores a single consistent meaning. One small thought: since several call sites recompute `getTimeOut() - (now - getStartTime())` themselves, might a short javadoc on `getTimeOut()` noting it's always the total-from-start (never "remaining") help keep someone from re-introducing a reassignment like this later? Non-blocking either way. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
