[Enhancement] Implement FastCodesHeader encode/decode for PullMessageRequestHeader/ResponseHeader

[wang-jiahua]

Before Creating the Enhancement Request

• I have confirmed that this should be classified as an enhancement rather than a bug/feature.

Summary

Implement FastCodesHeader.encode()/decode() for PullMessageRequestHeader and PullMessageResponseHeader to eliminate reflection-based header serialization.

Motivation

PullMessageRequestHeader and PullMessageResponseHeader already implement FastCodesHeader but their decode() methods use Map<String, String> instead of HashMap<String, String>, causing compilation issues with the interface. Additionally, their encode() methods can leverage R1's writeLong/writeInt helpers for numeric fields.

Describe the Solution You'd Like

Fix decode() signatures and optimize encode() methods on:

• PullMessageRequestHeader — 15 fields including Long/Integer types
• PullMessageResponseHeader — 4 fields

Additional Context

Depends on R1 (#10522, merged). Related PRs: #10443, #10526.

[RockteMQ-AI]

Issue Evaluation

Category: type/enhancement | Status: Evaluated

Feasibility: Feasible
Scope: remoting module — PullMessageRequestHeader, PullMessageResponseHeader
Dependency: R1 (#10522) via PR #10524 — ✅ Merged

Assessment:

• Both classes already implement FastCodesHeader with encode()/decode() methods.
• Current encode() uses writeIfNotNull() which converts all numeric fields (Long/Integer) to String via toString(), causing per-call allocation.
• With R1 merged, writeLong/writeInt helpers are now available in FastCodesHeader, enabling direct primitive writes without String boxing.
• PullMessageRequestHeader has ~15 fields (several Long/Integer), PullMessageResponseHeader has ~4 Long fields — meaningful allocation reduction at scale.

Minor note: The issue mentions decode() uses Map<String, String> vs HashMap<String, String> — current code on develop already uses HashMap<String, String> matching the interface signature. May have already been addressed or was a misreading.

This is a well-scoped optimization following the established pattern from R1.

---

Automated evaluation by RockteMQ-AI

[salmaloel657-dotcom]

I have reviewed the evaluation for issue #10534 regarding the FastCodesHeader implementation for PullMessageRequestHeader and PullMessageResponseHeader. It is great to see that the R1 dependency is merged and the writeLong/writeInt helpers are available to reduce allocations. Regarding the note on the decode() signatures, I will double-check the current develop branch to confirm if the HashMap<String, String> alignment has already been resolved as suggested by the AI evaluation.

…

On Sat, Jun 20, 2026, 9:08 PM RockteMQ-AI ***@***.***> wrote: *RockteMQ-AI* left a comment (apache/rocketmq#10534) <#10534 (comment)> *Issue Evaluation* Category: type/enhancement | Status: *Evaluated* *Feasibility:* Feasible *Scope:* remoting module — PullMessageRequestHeader, PullMessageResponseHeader *Dependency:* R1 (#10522 <#10522>) via PR #10524 <#10524> — ✅ Merged *Assessment:* - Both classes already implement FastCodesHeader with encode()/decode() methods. - Current encode() uses writeIfNotNull() which converts all numeric fields (Long/Integer) to String via toString(), causing per-call allocation. - With R1 merged, writeLong/writeInt helpers are now available in FastCodesHeader, enabling direct primitive writes without String boxing. - PullMessageRequestHeader has ~15 fields (several Long/Integer), PullMessageResponseHeader has ~4 Long fields — meaningful allocation reduction at scale. *Minor note:* The issue mentions decode() uses Map<String, String> vs HashMap<String, String> — current code on develop already uses HashMap<String, String> matching the interface signature. May have already been addressed or was a misreading. This is a well-scoped optimization following the established pattern from R1. ------------------------------ *Automated evaluation by RockteMQ-AI* — Reply to this email directly, view it on GitHub <#10534?email_source=notifications&email_token=CABFFMJQC4VKR4KGCR5VYU35A47Q5A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZWGA3DENZVHEZ2M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#issuecomment-4760627593>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CABFFMLST5TE24TJOGQSE2T5A47Q5AVCNFSNUABEKJSXA33TNF2G64TZHM3TKMJWGQ4DEMZ3JFZXG5LFHM2DOMBYHE4TCMJYGGQXMAQ> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CABFFMJNLQJTHOQFPE44SIT5A47Q5A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZWGA3DENZVHEZ2M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/CABFFMPDRFAT3TDOFNNEI535A47Q5A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZWGA3DENZVHEZ2M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[RockteMQ-AI]

Issue Evaluation

Category: type/enhancement | Status: Evaluated

Feasibility: Feasible
Scope: remoting module — PullMessageRequestHeader, PullMessageResponseHeader
Compatibility: Backward compatible — adds FastCodesHeader implementation alongside existing encode/decode.

Implementing FastCodesHeader for pull message headers avoids reflection-based field serialization on the pull path, which is one of the most frequently called RPCs. This is a straightforward optimization following the pattern already established by other header classes.

Good candidate for contribution.

---

Automated evaluation by RockteMQ-AI