If the first use of randomness by SQLite is for a WAL frame, and we have an error in xRandomness, then we end up with the Python error indicator set. But SQLite ignores the return of xRandomness (it is only used to seed the PRNG not for actual randomness), so the WAL stuff proceeds without SQLite indicating any error.
When control finally returns back to CPython land, we have the error indicator set, but SQLite is happy that everything worked. If we return OK to Python, then debug builds assertion fail because the error indicator was set. If we return ERROR then the Python code will try to do things like rollbacks on an already commit transaction which will be a bigger error.
Consequently xRandomness errors need to be silent on the callstack, but reported as unraiseable at the Python level.
After experimentation it is okay leaving this as a regular exception, and making connection_trace_and_exec look to PyErr_Occurred() before the SQLite error code.
If the first use of randomness by SQLite is for a WAL frame, and we have an error in xRandomness, then we end up with the Python error indicator set. But SQLite ignores the return of xRandomness (it is only used to seed the PRNG not for actual randomness), so the WAL stuff proceeds without SQLite indicating any error.
When control finally returns back to CPython land, we have the error indicator set, but SQLite is happy that everything worked. If we return OK to Python, then debug builds assertion fail because the error indicator was set. If we return ERROR then the Python code will try to do things like rollbacks on an already commit transaction which will be a bigger error.
Consequently xRandomness errors need to be silent on the callstack, but reported as unraiseable at the Python level.