qqeasonchen opened a new pull request, #5389: URL: https://github.com/apache/eventmesh/pull/5389
## What this PR adds Four feature-level e2e tests under `:eventmesh-runtime:test-e2e`, each driving a real RocketMQ broker end-to-end. These were previously covered only via `UniIngressService` + in-memory `MeshStoragePlugin` stubs, which means regressions in the broker-boundary code path (`EventMeshFrame` serialization, subscription lifecycle crossing the storage layer, partition routing in lite-pull consumer) had no failing signal. | Test | What it pins down | |---|---| | `BatchPublishOverBrokerTest` | A 10-event `publishBatch` round-trips over real `LitePullConsumer` — every event ID arrives. | | `UnsubscribeOverBrokerTest` | After `unsubscribe(topicA)`, topic A events no longer reach the subscriber while topic B continues — this is the case the in-process stub cannot catch, since dispatcher bookkeeping ≠ real-broker delivery routing. | | `RateLimitOverBrokerTest` | A 2-token bucket with 0 refill: 5 publishes produce 2 successes + 3 `RateLimitedException` rejects, AND the `rateLimited` counter ticks up by 3. The counter assertion is what catches "the limiter silently drops instead of rejecting". | | `RequestReplyOverBrokerTest` | A `/req` round-trip completes end-to-end over the broker, proving the request survives subscription rebalance before the responder's reply comes back. | ## Supporting changes 1. `FeatureBrokerHarness`: shared bootstrap that picks `rocketmq` (4.9 plugin) or `rocketmq5` based on `-Dit.feature.storage`, looks up the storage plugin via SPI (the same path production uses), boots `UniRuntime`, and tears it down. Skips cleanly when the plugin class is not present, so CI without a broker stays green. 2. `e2eFeature` gradle task: runs all four (or a selected one with `-Pfeature.test=FQN`). Reuses the existing `rocketmq4TestRuntimeClasspath` so `storage-rocketmq5` is excluded and the 4.9 plugin wins — same contract as `e2eTest4`. 3. `BrokerDiscoverer`: serialize admin RPC across the test JVM with a static lock. Without it, four tests creating topics back-to-back thrash the broker's single-shard topic-create / heartbeat thread and the namesrv route doesn't propagate in time (`"no broker for topic queue 0"`). ## Verified - All four tests pass **in isolation** against RocketMQ 4.9.5 over real `UniRuntime` on macOS / aarch64. - `./gradlew check -x spotlessJava -x :eventmesh-architecture-guard:test` remains green across storage-plugin (rocketmq, rocketmq5, kafka) and runtime modules. - The `e2eFeature` task is gated on `-Dit.feature.storage`; CI without a broker stays green. CI does not run it (opt-in gradle task outside the default `build` chain), so this PR adds no CI surface. ## Known broker artifact Running all four tests in a single `gradle :eventmesh-runtime:e2eFeature` invocation on a single-broker cluster is flaky under topic-creation pressure — the broker's topic-create / heartbeat thread becomes the bottleneck and routes don't propagate in time. Per-test (`-Pfeature.test=FQN`) runs are deterministic. Prefer `-Pfeature.test=…` in CI scripts that opt into this gate. Builds on #5388 (eventmesh-frame immutability, which made these tests viable again on RocketMQ5). -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
