-
Notifications
You must be signed in to change notification settings - Fork 393
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
InternalServerError: failed to lookup transaction or savepoint #3120
Comments
I've looked at this and I doubt we will fix it in 1.0. The problem is that the compiler eagerly evaluates the compiled query against its transactional state and assumes that once the query is compiled it will be executed. From the standpoint of the compiler, the first The way to fix this is to introduce some sort of phased synchronization between the IO process and the compiler: the compiler should build the state but not assume anything about it until the IO process actually confirms the execution. But I'm not sure how hard this would be to implement so I doubt we can (or should) fix this before 1.0. The risk of destabilizing the code base is too high imo. |
The OptimisticExecute was not ready for the Parse/Execute convention because it was always looking up in the cache and ignoring the Parse result. This was an issue because some statement is not cacheable and compiling again confused the state machine (#3120). Fixed in a way that the previously parsed result is used if the query hash matches, and dropped immediately on _execute() to mimic the legacy OptimisticExecute behavior. test_server_proto_tx_03() and _04() covers both cases.
The OptimisticExecute was not ready for the Parse/Execute convention because it was always looking up in the cache and ignoring the Parse result. This was an issue because some statement is not cacheable and compiling again confused the state machine (#3120). Fixed in a way that the previously parsed result is used if the query hash matches, and dropped immediately on _execute() to mimic the legacy OptimisticExecute behavior. test_server_proto_tx_03() and _04() covers both cases.
The OptimisticExecute was not ready for the Parse/Execute convention because it was always looking up in the cache and ignoring the Parse result. This was an issue because some statement is not cacheable and compiling again confused the state machine (#3120). Fixed in a way that the previously parsed result is used if the query hash matches, and dropped immediately on _execute() to mimic the legacy OptimisticExecute behavior. test_server_proto_tx_03() and _04() covers both cases.
* Drop support for protocol < 0.13 * Add v0-compatible protocol * Bump current protocol to 1.0 and preserve compatible support * Drop statement name of Parse/Prepare message * Drop statement name of Execute * Drop the DescribeStatement message * Rename make_describe_msg to make_command_data_description_msg * Drop the Execute message The OptimisticExecute was not ready for the Parse/Execute convention because it was always looking up in the cache and ignoring the Parse result. This was an issue because some statement is not cacheable and compiling again confused the state machine (#3120). Fixed in a way that the previously parsed result is used if the query hash matches, and dropped immediately on _execute() to mimic the legacy OptimisticExecute behavior. test_server_proto_tx_03() and _04() covers both cases. * Docs: rename Prepare -> Parse, OptimisticExecute -> Execute * Drop the "optimistic" wording in the code * Use edgedb 0.24.0a1
This is fixed |
The reason it was kept is explained in #3120, mitigated in #3814 #3837. But the core issue that compiler assumes mutation of transaction state for any compilation even by Parse message still exists. We can drop the `_last_anon_compiled` because the client bindings are no longer sending Parse + Execute for `commit` or `rollback` commands (which triggered two server compilation of the same command) like edgedb/edgedb-python#337. However, we still need to double check all bindings to make sure the transaction control commands are using only one `Execute` message.
Steps to Reproduce:
The text was updated successfully, but these errors were encountered: