zjncs opened a new pull request, #11123: URL: https://github.com/apache/rocketmq/pull/11123
## Motivation `DefaultRequestProcessor.putKVConfig` validates the decoded `namespace` and `key` but not `value`. The check matters more than `@CFNotNull` suggests: for headers that are not `FastCodesHeader`, `RemotingCommand.decodeCommandCustomHeaderDirectly` throws a `RemotingCommandException` for a missing `@CFNotNull` field but the surrounding per-field `catch (Throwable)` only logs it (`Failed field [value] decoding`), so a request without the value field decodes to a header with `value == null` instead of being rejected. The consequence: the nameserver answers `SUCCESS`, stores `kvTable.put(key, null)`, and every later `GET_KV_CONFIG` for that key answers `QUERY_NOT_FOUND` — the entry exists but is unreadable, and the persisted kvConfig JSON now carries a null value. ## Modification Extend the existing null check in `putKVConfig` to the value field and reject with `SYSTEM_ERROR` + `"namespace or key or value is null"`. ## Test Evidence New test class `DefaultRequestProcessorPutKVConfigTest` (plain setup, no reflection hacks, so it runs on any JDK). ``` docker exec rmq-build mvn -q -pl namesrv test -Dtest='DefaultRequestProcessorPutKVConfigTest' -Dsurefire.failIfNoSpecifiedTests=true ``` Before the fix: ``` org.apache.rocketmq.remoting.exception.RemotingCommandException: the custom field <value> is null (logged by the decode, then swallowed) testPutKVConfigWithoutValue: expected SYSTEM_ERROR but got SUCCESS (Tests run: 2, Failures: 1) ``` After the fix: ``` Tests run: 2, Failures: 0, Errors: 0, Skipped: 0 ``` No associated issue (self-discovered during a namesrv self-audit). -- 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]
