If a query run inside an explicit transaction results in a Neo4j server error, calling rollback afterwards puts the connection into an unusable state.
According to the Neo4j docs, all server-side errors automatically cause a transaction to rollback and close. This makes the explicit rollback superfluous, possibly even an error condition. However, even if calls to rollback on a closed transaction are indeed treated as an error, that should still not be affecting the underlying connection.
Attempts to resolve the situation by calling reset_cxn were not successful.
my $cxn = Neo4j::Bolt->connect(...);
my $txn = Neo4j::Bolt::Txn->new($cxn);
# This combination triggers the issue:
eval {
$txn->run_query("syntax error!");
$txn->rollback;
};
$txn = undef;
my @query = ( "RETURN \$text", {text => "Connection works!"} );
my $text = ( $cxn->run_query(@query)->fetch_next )[0];
say $text ? $text : "Failure";
# expected: Connection works!
# actually: Failure
$cxn->reset_cxn;
say 'Connection err ', join ' ', $cxn->errnum, $cxn->errmsg;
# Connection err -16 Connection closed
(I ran into this issue while overhauling the error handling of Neo4j::Driver.)
If a query run inside an explicit transaction results in a Neo4j server error, calling
rollbackafterwards puts the connection into an unusable state.According to the Neo4j docs, all server-side errors automatically cause a transaction to rollback and close. This makes the explicit rollback superfluous, possibly even an error condition. However, even if calls to
rollbackon a closed transaction are indeed treated as an error, that should still not be affecting the underlying connection.Attempts to resolve the situation by calling
reset_cxnwere not successful.(I ran into this issue while overhauling the error handling of Neo4j::Driver.)