There's no difference between the implementation for the two `count` functions of `GroupedStreamImpl`

[elenacliu]

Maybe the second count function of which declaration is public <OUT> GroupedStream<K, Integer> count(SelectAction<OUT, V> selectAction) may do count operation based on whether the key exists or not?

[ni-ze]

count(SelectAction<OUT, V> selectAction) is plan to calculate the count of the special key. But the implementation is be forgotten.

can you submit a pr to make it correct?

[elenacliu]

count(SelectAction<OUT, V> selectAction) is plan to calculate the count of the special key. But the implementation is be forgotten.

can you submit a pr to make it correct?

sure, I'll do it in the following days.

[RockteMQ-AI]

Issue Evaluation

Category: bug | Status: Needs Investigation

Analysis: If the two count functions in GroupedStreamImpl have identical implementations, one of them is likely incorrect or redundant. The second count function with SelectAction<OUT, V> parameter should potentially perform a conditional count (counting only when the key exists or when a condition is met).

Requested information:

• Expected behavior of each count variant
• Whether this is a copy-paste error or intentional
• Test cases that demonstrate the expected difference

---

Automated evaluation by RockteMQ-AI

[RockteMQ-AI]

Issue Evaluation

Category: question | Status: Evaluated

The observation is valid — if both count() overloads in GroupedStreamImpl produce identical results, one of them may be redundant or incorrectly implemented.

The count() without a SelectAction should count all records per key, while count(SelectAction<OUT, V>) should count based on a projected value. If they behave identically, the second overload may not be applying the SelectAction correctly.

This needs a code review of GroupedStreamImpl to confirm whether the SelectAction is being properly applied in the second variant.

---

Automated evaluation by github-manager

[RockteMQ-AI]

Issue Evaluation\n\nCategory: bug | Status: Confirmed\n\nValid issue. Identical implementations for two different count functions suggests a copy-paste error or missing differentiation.\n\nSeverity: Low-Medium — correctness concern.\n\n---\nAutomated evaluation by github-manager

[RockteMQ-AI]

Issue Evaluation

Category: bug | Status: Confirmed

If the two count function overloads in GroupedStreamImpl have identical implementations, the variant with SelectAction parameter is not performing the expected key-based counting. The SelectAction variant should count based on a projected value, not just key existence.

Root Cause: Copy-paste error or incomplete implementation — the SelectAction overload likely should delegate to a different counting logic.
Impact: Incorrect aggregation results when using the SelectAction variant.
Severity: Medium

---

Automated evaluation by RockteMQ-AI

[RockteMQ-AI]

Issue Evaluation

Category: bug | Status: Confirmed

The two count functions in GroupedStreamImpl showing no difference suggests a code duplication or implementation error.

Root Cause: Likely duplicate method implementations or incorrect delegation.
Impact: Code quality — may cause confusion or incorrect aggregation results.
Severity: low

---

Automated evaluation by github-manager-bot

[RockteMQ-AI]

Issue Evaluation

Category: bug | Status: Confirmed

This is a real bug. Analysis of GroupedStreamImpl.java:

• Line 64 and Line 80: Both count() methods have identical implementations — both use (key, value, agg) -> agg + 1
• The selectAction parameter is completely ignored — no null-check, no usage
• Inconsistent with API convention: Sibling methods like sum(SelectAction), min(), max() all properly use their selector parameters. Only count() drops it.
• Silently wrong behavior: Example code calls .keyBy(User::getAge).count(User::getName) expecting field-based counting, but gets plain per-record counting with no warning.

Suggested fix direction:

1. Either implement the selector logic (e.g., count only when selected field is non-null, or count distinct values)
2. Or deprecate/remove the parameter if the behavior is intentionally identical

The exact semantics should be clarified with maintainers, but silently ignoring a parameter is definitely a defect.

---

Automated evaluation by RockteMQ-AI