Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
fix: fix issues with multi-statement requests failing to validate (#3952
) fixes: #3363 Issue was that the `prepare` call is throwing if the meta-store doesn't contain the sources in a statement. Given a request contains a later statement that depends on an earlier statement, e.g. ```sql CREATE STREAM FOO (...) WITH (...); CREATE STREAM BAR AS SELECT * ``` The KSQL correctly validates the statements, because it updates the sandboxed copy of the meta-store as it goes. However, when it comes to executing the statement it once against `prepares` the statement. Only this time its using the true meta-store and that is only updated by the command runner thread. This can mean that the first statement is correctly written to the command topic, but if the next statement is `prepare`'d before the command runner thread executes the statement and updates the meta-store, then the `prepare` call on the rest-request thead will fail with an error that `FOO` does not exist. The server has the ability to wait for a previous command to be executed by the command runner thread before executing the next. However, this isn't done for _distributed_ statements, i.e. those written to the command topic as its not meant to be required. It is done for statements such as `SHOW STREAMS`, which need to have any previous command executed as it may be creating a stream! This is fixed in master already. The fix was to _not_ have `prepare` validate that the source exists. This is the correct fix. However, this would be a big change for 5.4.x. Instead, this commit makes two changes: 1. Move the check to wait for previous commands to _before_ the `prepare` call. 2. All statement types should wait for previous commands to finish. (Because we check _before_ `prepare` we don't _know_ the statement type). This fixes the race condition at the cost of more synchronisation. However, this synchronisation will only impact multi-statement requests. The CLI generally issues single line requests, so no impact. C3 issues multi-line requests, i.e. the entire script in one go. So this will slow down responses to C3 slightly, but will stop intermittent fails in C3 if there are interdependent statements.
- Loading branch information