fightBoxing commented on issue #4172: URL: https://github.com/apache/amoro/issues/4172#issuecomment-4319777068
### Status update I opened a first attempt at a fix in #4195, but after submitting it I discovered that \`master\` has recently received a large scheduling-framework refactor that: - moves \`TableRuntimeRefreshExecutor\` from \`server/table/executor/\` to \`server/scheduler/inline/\`, - switches its parent from \`BaseTableExecutor\` to \`PeriodicTableScheduler\`, - splits \`TableRuntime\` into an interface (\`o.a.amoro.TableRuntime\`) and an implementation (\`DefaultTableRuntime\`), - changes \`OptimizingProcess.getStatus()\` to return \`ProcessStatus\` (cross-module), - changes \`OptimizingProcess.close()\` to \`close(boolean needCommit)\`. #4195 is based on the pre-refactor layout and therefore has heavy merge conflicts. **The root-cause analysis and the fix direction are still valid**: \`OptimizingQueue.acceptResult()\` does call \`tableRuntime.beginCommitting()\` once when the last task finishes, but if that single call fails transiently (e.g. the DB lock wait timeout shown in the stack trace here), there is no retry path and the table stays in \`*_OPTIMIZING\` forever until AMS restart. A periodic self-heal in the refresh executor is still the right place to fix this. I'll: 1. close #4195, 2. rebase the fix onto the current \`master\` / new scheduler framework, 3. open a fresh PR adapted to \`DefaultTableRuntime\` / \`ProcessStatus\` / \`PeriodicTableScheduler\` and reference it here. Thanks for your patience. -- 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]
