minxhe commented on PR #29575: URL: https://github.com/apache/flink/pull/29575#issuecomment-6505147036
> The adaptor fix looks correct. While checking the same null-removal contract in native ForSt, I noticed that `ForStDBBunchPutRequest.process()` still serializes null-valued entries instead of deleting their keys. I reproduced this in a focused native write-batch test: updating an existing key with a null value leaves the key present. > > This path is unchanged by this PR, so I don't consider it a blocker for the adaptor fix. Would it make sense to track this separately and reuse the null-removal scenarios for native ForSt? Thanks for checking the ForSt side. It's tracked separately in [FLINK-41091](https://issues.apache.org/jira/browse/FLINK-41091) / #29571. That PR turns null-valued `asyncPutAll` entries into deletes in `ForStDBBunchPutRequest#process`, and rejects a `null` map before it reaches the whole-map `CLEAR` path. `ForStStateExecutorTest#testExecuteMapPutAllWithNullValues` there covers your repro: an existing key updated to `null` is removed and `asyncContains` returns `false`. Other tests cover all-null maps, empty maps, request order, and a `null` map. Reviews on #29571 are welcome. -- 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]
