wilmerdooley opened a new pull request, #22562: URL: https://github.com/apache/kafka/pull/22562
## Change description When `KTable.transformValues` is called with extra state stores (via the `stateStoreNames` parameter) and the result is not materialized, the resulting `KTableTransformValues` `ProcessorSupplier` did not expose those extra stores via `storeNames()`. As a result, a downstream `KTable` join operator had no way to learn about the extra stores and could not wire them through to the join processor, causing initialization to fail with `Processor ... has no access to StateStore ...`. This change adds a new constructor to `KTableTransformValues` that accepts the `stateStoreNames` and merges them with the parent value getter's `storeNames()` so the full set of stores is reported. `KTableImpl` now passes the `stateStoreNames` it already received to this new constructor. Tests are added in `KTableTransformValuesTest` and `KTableKTableInnerJoinTest` to cover both the unit-level `storeNames()` behavior and the end-to-end join scenario from the issue. ### Testing strategy Unit tests verify that the `view()` `storeNames()` method of `KTableTransformValues` returns the union of parent store names and the extra `stateStoreNames` when the result is not materialized. A new integration-style test in `KTableKTableInnerJoinTest` reproduces the exact scenario from KAFKA-19602: a `transformValues` on a `KTable` with an extra manually-added state store, followed by a self join, which previously failed during topology initialization. JIRA: https://issues.apache.org/jira/browse/KAFKA-19602 -- 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]
