[balbesina]

Problem

ActiveRecordLogSubscriber#sql appends every query to Lograge::Sql.store[:lograge_sql_queries], in any thread. The list is only drained when Lograge logs a request. In a thread that never serves a request, it grows for the life of the process.

Some examples of such threads:

• Sidekiq (or any other job runner) worker threads.
• Action Cable worker threads (connect, subscribed, ...).
• Any background thread the app starts.

This is the same leak as #59. The Solid Cable denylist added in #60 covers one source of it; any other query source outside a request still leaks.

In our case, a heap dump of a Sidekiq process that had been running for about 3 hours held 100k entries in a single worker thread's store. Memory grew by about 150 MB/h until the pod was OOM-killed.

Fix

Lograge::Sql.store_active? reports whether events should be stored right now. The subscriber skips the event when it returns false.

• When RequestStore is loaded (Lograge depends on it), the method returns RequestStore.active?. That is true only between RequestStore::Middleware's begin! and end!, which is exactly the span of a request that Lograge will log and drain.
• When RequestStore is not loaded, or is too old to have active?, the behaviour doesn't change.

Requests are logged exactly as before.

Specs

• With a request open, the event is stored.
• With no request open, the event is not stored.
• The existing examples now run inside an open request.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud