Repository navigation
Conversation
BaseScheduleAgentTask.run(...) already increments the execution count, so the second increment in XxlJobAgentScheduler.executeAgent made one job trigger report two executions. The Quartz job leaves the counting to run(...) alone, and QuartzFixedDelayIntegrationTest asserts that one-to-one mapping. Add a regression test that drives the registered IJobHandler with a canned model and asserts the counter is 1 after a single trigger.
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
AgentScope-Java Version
2.1.0-SNAPSHOT
Description
Fixes #3508
BaseScheduleAgentTask.run(...)already increments the execution count, andXxlJobAgentScheduler.executeAgentincremented it a second time after the run returned, so a single XXL-Job trigger reported two executions:The Quartz job leaves the counting to
run(...)alone --AgentQuartzJob.executeonly callst.run(inputMsg).block()-- which is what letsQuartzFixedDelayIntegrationTestassert a one-to-one mapping between firings andgetExecutionCount(). XXL-Job drifted from that contract, so anyone reading the counter for metrics, alerting or back-off decisions over XXL-Job sees a value that is exactly twice the truth.The skew is also asymmetric. When the agent run throws,
run(...)has already counted once and the failing path never reaches the second increment (executeAgentrethrows as aRuntimeException), so failed triggers counted 1 while successful ones counted 2 -- the ratio between them was wrong too, not just the absolute value.XxlJobAgentScheduler.executeAgent, with a comment recording why it must not come back.XxlJobExecutor.loadJobHandler(...), fires it once, and assertsgetExecutionCount() == 1.Red on
16632ae84(currentmain):Green with the fix:
Validation on commit dce9a38:
XxlJobAgentSchedulerTest: 35 passed, 0 failures.agentscope-extensions-scheduler-common: 80 passed, 0 failures (includesBaseScheduleAgentTaskTest, which pins the "run(...)counts once" half of the contract).agentscope-extensions-scheduler-quartz: 66 passed, 0 failures (includesQuartzFixedDelayIntegrationTest, the sibling that asserts the invariant end to end).mvn spotless:applyclean; JDK 17.IJobHandlerdirectly, which is the same entry point XXL-Job itself calls.Checklist
mvn spotless:applymvn test) -- the three scheduler modules passed; the full reactor cannot finish in this sandbox (agentscope-core'sDangerousPathBypassTestneeds symlink privileges that the machine does not grant)