Frun1na commented on PR #6514: URL: https://github.com/apache/rocketmq-dashboard/pull/6514#issuecomment-6194158414
Thanks for tracing every consumer of the sentinel. I've rebased this branch onto `rocketmq-studio` (now on top of #6655; `MetadataServiceTest` passes, 60/60). The other surfaces are either covered by open PRs or already correct on the base, so I've kept this PR to the export column: 1. **Frontend type, table column + sorter, detail panel** (your points 1–3) — #5920 by @unbridled-41, the console PR for #5919, makes exactly these changes: it adds `consumptionTimestampAvailable` to `ConsumerGroup` in `web/src/api/metadata.ts`, renders the delay column through `isDelayAvailable(...)` with a `delaySortValue` that keeps unmeasured groups out of the numeric order (same pattern as `lagSortValue`), and applies the same check to the detail Statistic. Its branch still merges cleanly into the current base. Redoing those changes here would duplicate that PR and put both in the `consumer.tsx` / `ConsumerPage.test.tsx` collision cluster you mentioned. 2. **AI contract** (point 4) — `GroupDetailOutput` is handled by my #6106: `delaySeconds` becomes a nullable `Integer` that is `null` unless `consumptionTimestampAvailable`, and `delaySeconds` is dropped from the `rmq.group.detail` required list in `group.yaml`. I've just rebased it onto the current base; the only conflict was the regenerated digest in `catalog_gen.go`, and `make catalog-verify` passes. `GroupInput.delaySeconds` is left as is on purpose. It's the writable field of `rmq.group.update` (the same field `CreateConsumerGroupDTO` sets), and `GroupInput.from(current)` only builds the before/after diff for the confirm preview. If it were nulled whenever the timestamp is missing, a `delaySeconds` the caller explicitly sets on such a group would be dropped from the preview. 3. **Metrics gauge** (point 5) — this one is already handled on the base. `ApacheRocketMqBusinessMetricsCollector` calls `delaySample(...)` only when `group.isConsumptionTimestampAvailable()` is true (`:96-97`); otherwise it emits an `unavailable` sample with reason `CONSUMER_TIMESTAMP_UNAVAILABLE` (`:98-104`). So the `Math.max(0, getDelaySeconds())` at `:129` only ever runs on a measured delay. If you'd rather have the console part in this PR anyway, let me know and I'll coordinate with @unbridled-41 first. -- 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]
