fix(common): restore eager task queue offer policy - #7482

Reviewed current head 844b120ee3f4.

The queue offer policy fix is source-correct, and exact-head ShenyuThreadPoolExecutorTest passed.

Validation: exact-head targeted Maven reactor tests passed on Java 17.

./mvnw -pl shenyu-common -am test -Dtest=ShenyuThreadPoolExecutorTest -Dsurefire.failIfNoSpecifiedTests=false -Drat.skip=true -Djacoco.skip=true -DskipRemoteResources=true -Dmaven.javadoc.skip=true

GitHub still reports failing checks: e2e, e2e-case (e2e-logging-rabbitmq-compose, shenyu-e2e-case-logging-rabbitmq, :shenyu-examples-http). This review does not claim those checks have passed.

Review: fix(common): restore eager task queue offer policy

Reviewed the change against TaskQueue, MemorySafeTaskQueue, MemoryLimitedTaskQueue, and their LinkedBlockingQueue superclasses at head 5d1244b.

Root cause (confirmed)

TaskQueue<E> extends BlockingQueue<E> defines a default offer(E) that implements the eager-growth policy:

• if activeCount < poolSize → doOffer(e) (idle worker exists, enqueue),
• else if poolSize < maximumPoolSize → return false (let the executor spawn a new worker),
• else → doOffer(e) (at max, enqueue).

MemorySafeTaskQueue/MemoryLimitedTaskQueue extend concrete LinkedBlockingQueue subclasses (MemorySafeLinkedBlockingQueue/MemoryLimitedLinkedBlockingQueue) that provide their own concrete offer(E). Because a concrete superclass method takes precedence over an interface default, calls to queue.offer(task) from ShenyuThreadPoolExecutor dispatched to the physical enqueue instead of the eager-growth default — exactly the "tasks remain queued while max still allows additional workers" symptom described in #7463. Both production implementations were affected, so a pool with maximumPoolSize > corePoolSize (including the websocket reconnect executor at 1/8) would not grow under load.

Fix (correct)

• Both classes now explicitly override offer(Runnable) and delegate to TaskQueue.super.offer(runnable), invoking the interface default. TaskQueue.super.offer is valid Java and resolves to the intended policy.
• doOffer(Runnable) still calls super.offer(runnable), i.e. the physical enqueue in the LinkedBlockingQueue subclass, which retains the existing memory guard (MemorySafeLinkedBlockingQueue.offer / MemoryLimitedLinkedBlockingQueue.offer check free memory before enqueueing). Memory-safety semantics are therefore preserved; only the dispatch target of offer changes.

Tests (adequate)

• ShenyuThreadPoolExecutorTest now parameterizes over both queue implementations via taskQueues().
  • testGrowsWhenCoreWorkerIsBusy: pins the single core worker and submits a second task; with the fix the eager-growth policy returns false and a second worker is created, so the second submit(...).get() returns within the timeout. This directly exercises the bug fix.
  • testOffersToIdleWorker: mocks EagerExecutorService (poolSize=2, activeCount=1, max=3) and asserts offer enqueues + poll returns the same task — covers the idle-worker branch.
• Referenced constructors (MemorySafeTaskQueue(int maxFreeMemory), MemoryLimitedTaskQueue(Instrumentation)) exist. MemorySafeTaskQueue<>(1) sets maxFreeMemory=1, and since isAvailable() checks maxAvailable() > maxFreeMemory, the JVM's free memory is always well above 1, so the assertion is stable (not flaky).
• testNullCommand remains valid after the getTestExecutor signature change (core/max 1/2 still throws NPE on execute(null)).

CI

All checks green (build, Analyze/CodeQL, the full integrated/e2e matrix, agent_gateway_migrations, rat/license/changes).

Non-blocking suggestion

The shadowing of an interface-default offer by a superclass concrete offer is subtle. A one-line comment on the new offer override (e.g. "delegate to TaskQueue's eager-growth default; do not call super.offer here or the growth policy is bypassed") would help future maintainers avoid re-introducing the regression.

LGTM — approving. Good catch and clean, well-tested fix.