fix(harness): prevent missed wakeups during startup

[HeadBro1]

AgentScope-Java Version

2.0.0-SNAPSHOT

Description

WakeupDispatcher previously drained the durable wakeup queue before subscribing to the transient wakeup signal. A wakeup enqueued between those operations could remain queued until another signal arrived. Startup recovery also drained only one batch of 64 entries, so a larger backlog could remain unprocessed without a follow-up signal.

This PR:

• subscribes to wakeup signals before performing the startup drain
• continues draining full batches until the durable queue contains fewer than 64 entries
• adds regression tests for the startup subscription window and a 65-entry backlog

Tested with:

mvn -pl agentscope-harness -am -Dtest=WakeupDispatcherTest -Dsurefire.failIfNoSpecifiedTests=false test

All 6 WakeupDispatcherTest tests pass.

Checklist

Please check the following items before code is ready to be reviewed.

• Code has been formatted and passes Spotless checks
• All tests are passing (mvn test) — targeted harness tests pass; the full suite was not run locally
• Javadoc comments are complete and follow project conventions
• Related documentation has been updated (no external documentation changes are required)
• Code is ready for review

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

“caihr” seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[HeadBro1]

Reopening to retrigger CI after an unrelated transient JUnit temp-directory cleanup failure.

[codecov]

Codecov Report

❌ Patch coverage is 90.00000% with 1 line in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...tscope/harness/agent/gateway/WakeupDispatcher.java	90.00%	0 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!

[AgentScopeJavaBot]

🤖 AI Review

This is a clean, well-targeted bug fix addressing two real race conditions in WakeupDispatcher.start():

1. Subscribe-before-drain reorder: The old order (drain → subscribe) had a window where a wakeup enqueued after the drain but before the subscription could sit unprocessed until the next signal. The fix correctly subscribes first, then drains — the standard "subscribe-then-catchup" pattern.

2. Full queue drain loop: The old code drained only one batch of 64 entries on startup. The fix loops until entries.size() < MAX_DRAIN_COUNT, ensuring backlogs larger than 64 are fully processed.

Both regression tests are well-designed: startup_subscribesBeforeInitialDrain uses a clever EnqueueOnSubscribeMessageBus to inject a wakeup at the exact moment of subscription, and initialDrain_processesMoreThanOneBatch pushes 65 entries to validate the loop fix. The code is correct, thread-safe (concurrent drain calls get disjoint entry sets; dispatch is idempotent via isSessionRunning guard), and introduces no new issues.

[AgentScopeJavaBot]

🤖 AI Review

This is a clean, well-targeted bug fix addressing two real race conditions in WakeupDispatcher.start():

1. Subscribe-before-drain reorder: The old order (drain → subscribe) had a window where a wakeup enqueued after the drain but before the subscription could sit unprocessed until the next signal. The fix correctly subscribes first, then drains — the standard "subscribe-then-catchup" pattern.

2. Full queue drain loop: The old code drained only one batch of 64 entries on startup. The fix loops until entries.size() < MAX_DRAIN_COUNT, ensuring backlogs larger than 64 are fully processed.

Both regression tests are well-designed: startup_subscribesBeforeInitialDrain uses a clever EnqueueOnSubscribeMessageBus to inject a wakeup at the exact moment of subscription, and initialDrain_processesMoreThanOneBatch pushes 65 entries to validate the loop fix. The code is correct, thread-safe (concurrent drain calls get disjoint entry sets; dispatch is idempotent via isSessionRunning guard), and introduces no new issues.