That's correct.
And yes, it's a public contract and thus a KIP would be needed to change
(or remove it). Deprecation implies that the API is kept for at least 3
releases (ie, one year), plus it can only be removed in a major release.
For example, if we deprecated something in 2.1 release, we could have
removed it in 3.0. If we deprecated something in 2.7 release, (there was
only 2.8 and than 3.0), we can only remove in 4.0 (only 2.6 or earlier
deprecated things could be removed in 3.0 to meet the 3 releases / one
year requirement).
But I am not sure if we would really remove the processor, or actually
change the restore path instead. Last but not least, if there would be
KIP about removing it, the main goal would be to hide the store from
user code, so we could still allow to register some "call-back
processor" that has no access to the state store itself.
-Matthias
On 7/26/23 10:39 AM, Colt McNealy wrote:
Hi all,
In this JIRA ticket: https://issues.apache.org/jira/browse/KAFKA-7663 it's
documented that Global Stores are bypassed on restoration.
Consequently, the input topic to a Global Store needs to essentially be a
changelog topic as the keys and values are copied directly into the store.
I heard (perhaps in the Slack) a while ago that there was some conversation
about removing the ability to supply a Processor to the Global Store to
prevent users from tripping over that behavior. However, we currently rely
on the Processor to notify other parts of our application that things have
changed in the store (eg. for cache invalidation, metrics, etc). Obviously,
we make sure to respect the semantics of how the processor+global store
works for restoration etc...
It seems to me like the fact that we can pass in a Processor is a public
API contract, so it should be safe to rely on that...? Would it require a
KIP to change the fact that we can pass in a Processor? How much
deprecation notice would we have before we need to find a new solution?
Thanks,
Colt McNealy
*Founder, LittleHorse.dev*
