⚠️ Potential issue | 🟠 Major

#!/bin/bash
# Search for the Drop implementation and statement cleanup patterns

echo "=== Current Drop implementation for Sqlite ==="
rg -n -A5 'impl Drop for Sqlite' crates/stdlib/src/sqlite.rs

echo -e "\n=== Finding Statement creation and lifecycle management ==="
rg -n -B3 -A5 'struct SqliteStatement|fn new.*Statement' crates/stdlib/src/sqlite.rs | head -80

echo -e "\n=== Finding drop_db calls and connection closure ==="
rg -n -B2 -A8 'fn drop_db' crates/stdlib/src/sqlite.rs

echo -e "\n=== Checking cursor statement cleanup ==="
rg -n -B3 -A10 'impl Drop for Cursor' crates/stdlib/src/sqlite.rs

echo -e "\n=== Searching for Cursor close methods ==="
rg -n -B2 -A8 'fn close\(' crates/stdlib/src/sqlite.rs | head -80

#!/bin/bash
# Search for Cursor struct definition and statement storage

echo "=== Finding Cursor struct definition ==="
rg -n -B5 -A20 'struct Cursor' crates/stdlib/src/sqlite.rs | head -100

echo -e "\n=== Finding how statements are stored/managed ==="
rg -n -B3 -A3 'description:|\.stmt|self\.stmt' crates/stdlib/src/sqlite.rs | head -100

echo -e "\n=== Finding execute methods that create statements ==="
rg -n -B2 -A15 'fn execute\(' crates/stdlib/src/sqlite.rs | head -150

echo -e "\n=== Search for statement finalization patterns ==="
rg -n 'sqlite3_finalize|finalize_stmt' crates/stdlib/src/sqlite.rs

#!/bin/bash
# Get the complete Cursor.close() implementation
echo "=== Cursor close method complete implementation ==="
sed -n '1822,1860p' crates/stdlib/src/sqlite.rs

echo -e "\n=== Connection.drop_db() and its usage ==="
sed -n '941,950p' crates/stdlib/src/sqlite.rs

echo -e "\n=== Check if statements are cleaned up before drop_db ==="
rg -n -B10 'drop_db' crates/stdlib/src/sqlite.rs | grep -A10 -B10 'close\|drop_db'

echo -e "\n=== Check what Cursor has when close is called ==="
sed -n '1820,1860p' crates/stdlib/src/sqlite.rs

#!/bin/bash
# Find Statement struct definition
echo "=== Finding Statement struct definition ==="
rg -n -B3 -A15 'struct Statement' crates/stdlib/src/sqlite.rs

echo -e "\n=== Check Statement::new implementation ==="
rg -n -B2 -A20 'impl Statement' crates/stdlib/src/sqlite.rs | head -100

echo -e "\n=== Verify if Statement holds connection reference ==="
rg -n 'struct Statement \{' -A20 crates/stdlib/src/sqlite.rs

Ensure all cursors are closed before closing the connection, or use sqlite3_close_v2 to defer close until statements finalize.

The change from sqlite3_close_v2 to sqlite3_close introduces a resource leak risk:

• sqlite3_close returns SQLITE_BUSY if unfinalized statements exist and fails silently in Drop
• Connection.close() calls drop_db() immediately while active Cursor objects may still hold prepared statements
• Statements only finalize when their owning Cursor is dropped, which may happen after the connection is dropped

Either:

1. Ensure statements are explicitly finalized before Connection.close() is called
2. Revert to sqlite3_close_v2 for more resilient cleanup semantics
3. Add explicit statement cleanup in drop_db() before closing the connection

@ever0de Is this looking a correct review?

Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!

I created comprehensive tests comparing CPython's behavior with RustPython when closing connections with active cursors. Both implementations behave identically - they successfully close the connection even when cursors remain active, and subsequent cursor operations properly raise ProgrammingError.

Investigation of sqlite3_close vs sqlite3_close_v2:
While CPython does use sqlite3_close_v2() for its deferred cleanup semantics, libsqlite3-sys intentionally removed sqlite3_close_v2 from its API in version 0.29.0 (rusqlite/rusqlite@4390720).

The commit message explicitly states:

Omit API

sqlite3_close_v2 (for gced languages)

The rationale is that sqlite3_close_v2 is specifically designed for garbage-collected languages where destructor order is non-deterministic. In Rust, with its deterministic RAII-based resource management, the v2 variant is unnecessary. The library maintainers deliberately chose to expose only sqlite3_close as the canonical close function for Rust applications.

This means the use of sqlite3_close() in this PR is not only necessary due to API constraints but also aligns with rusqlite's design philosophy.

Why it works safely:
Our implementation is safe because:

1. The drop_db() method takes ownership via .take(), ensuring clean Drop trait execution
2. Statement finalization happens through RAII when SqliteStatement is dropped
3. The existing test suite (including the new tests I created) confirms proper cleanup behavior
4. Rust's ownership system guarantees deterministic cleanup order, unlike garbage-collected languages

The current implementation matches CPython's observable behavior even though the internal mechanism differs due to library design decisions.

Thank you for confirming!