You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sandboxed objects were implemented in KSQL to validate statements when some calls to Kafka were needed. The validation should not execute any real call (i.e. delete topics, create, etc). During a validation, the full execution path is tested. For instance, in the case of persistent queries, the validation will check a query is removed from the query registry, new queries are being added to the registry, etc. To do that, the validation process creates a sandbox for the query registry to prevent real queries are indeed removed, stopped.
However, Kafka streams are not sandboxed, and thus a new stream is executed and stopped during the validation. But old queries aren't stopped, so it caused an issue during CREATE OR REPLACE when the new query wanted to access the same materialized store.
If old queries are sandboxed to prevent stopping them, I think we should also sandbox new queries to prevent starting them and stopping them. This requires some refactoring in the code to sandbox the new persistent query metadata and implement no-op methods that deal with kafka streams.
The text was updated successfully, but these errors were encountered:
This code issue is found by #8130
Sandboxed objects were implemented in KSQL to validate statements when some calls to Kafka were needed. The validation should not execute any real call (i.e. delete topics, create, etc). During a validation, the full execution path is tested. For instance, in the case of persistent queries, the validation will check a query is removed from the query registry, new queries are being added to the registry, etc. To do that, the validation process creates a sandbox for the query registry to prevent real queries are indeed removed, stopped.
However, Kafka streams are not sandboxed, and thus a new stream is executed and stopped during the validation. But old queries aren't stopped, so it caused an issue during CREATE OR REPLACE when the new query wanted to access the same materialized store.
If old queries are sandboxed to prevent stopping them, I think we should also sandbox new queries to prevent starting them and stopping them. This requires some refactoring in the code to sandbox the new persistent query metadata and implement no-op methods that deal with kafka streams.
The text was updated successfully, but these errors were encountered: