123123213weqw opened a new pull request, #5755: URL: https://github.com/apache/rocketmq-dashboard/pull/5755
## What\n\n`AiRunExecutor.submit` handles a stop that lands between registration and submission by finalising the run itself (`finalizeRun` is exactly-once). But the worker task handed to the executor may already be scheduled, and when it ran, `execute` started with `markRunning`, which writes `status = RUNNING` over the terminal row the admission thread had just written.\n\n## Why it is a bug\n\nThe final state of the row became `RUNNING` with nobody owning the run: the worker's own `finalizeRun` is a no-op (the CAS already lost), and the registry entry is finished. The conversation then behaves exactly like an orphaned run — every later turn refused with 409 "busy" — until the scheduled orphan sweep reaps the row.\n\n## The fix\n\n`execute` checks `context.isTerminal()` first and returns before `markRunning`: when `submit` (or anything else) already won the terminal write, the worker must not touch the row at all. The `finally` block still runs, keeping `finalizeRun`/`regist ry.finish` idempotent.\n\n## Test\n\nRed-first: `AiRunServiceTest.aWorkerThatStartsAfterFinalisationMustNotResurrectTheRunTest` parks the worker task in a deferred executor, stops the handle before submission (so `submit` writes `STOPPED`), then releases the queued worker and asserts the row still says `STOPPED`. Fails with `RUNNING` on the previous code, passes with the guard; the class (23 tests) stays green. -- 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]
