fix: scope query counting to the measuring thread

The synchronous benchmark subscribed to sql.active_record process-wide
while a worker ran on its own thread, so whatever the worker polled
during the window landed in the count. Stability across runs made that
look deterministic when it was only consistent.

Counting is now scoped to the thread being measured, and the caller and
the worker turn are measured separately rather than by watching both at
once, because a poll belongs to no particular call.

This corrects a claim made in the previous commit. The caller of a
synchronous call costs 49 queries, exactly what was documented before;
the 53 reported earlier was four stray polls. The message turn drift is
real and stands at 26 against a documented 29, since that measurement
always ran on the measuring thread with nothing else alive. The script
also reports the total a synchronous call costs the database, 75, which
was never recorded.

Author: cardmagic

CHANGELOG.md

@@ -8,9 +8,12 @@
   prints the refusal and the setting that grants access, and exits 1.
 - Measure the query count for a synchronous call. `benchmark/query_count.rb`
   only measured a worker turn, so the documented synchronous number had no
-  script behind it and had drifted: a message turn costs 26 queries rather than
-  the documented 29, and a synchronous call 53 rather than 49. Both are
-  deterministic and now reported by the same script.
+  script behind it. It reports three now: a message turn costs 26 queries
+  rather than the documented 29, the caller of a synchronous call costs 49, and
+  a synchronous call in total costs 75, being a caller plus the turn it waits
+  on. Counting is scoped to the measuring thread, since a worker loop polls
+  whether or not a call is in flight and a process-wide count folds those polls
+  into the result.
 
 - Run payload broadcast blocks against the actor instance, like every other
   block in the actor DSL. `self` was the actor class, so an actor instance

benchmark/support.rb

@@ -291,45 +291,55 @@ def component_delivery
 
     # @rbs () -> void
     def query_count
-      message_turn_query_count
-      synchronous_query_count
+      turn = message_turn_query_count
+      caller_queries = synchronous_caller_query_count
+      puts "database queries: #{turn} for 1 message turn"
+      puts "database queries: #{caller_queries} for the caller of 1 synchronous call"
+      puts "database queries: #{caller_queries + turn} for 1 synchronous call, caller plus the turn it waits on"
     end
 
     private
 
-    # @rbs () -> void
+    # Runs the turn on the measuring thread, so nothing else can contribute.
+    # @rbs () -> Integer
     def message_turn_query_count
       CounterActor.ref("queries").async(:increment)
       worker = SolidObjects::Worker.new
-      processed = nil
-      queries = count_queries { processed = worker.run_once }
-      puts "database queries: #{queries} for #{processed} message"
+      count_queries { worker.run_once }
     ensure
       worker&.stop
     end
 
     # A synchronous call also registers or heartbeats the caller process,
-    # claims the activation, and observes the result, so it costs more than the
-    # worker turn it contains. The first call is discarded because it pays for
-    # activation and caller registration that a steady-state call does not.
-    # @rbs () -> void
-    def synchronous_query_count
+    # claims the activation, and observes the result, so the caller costs more
+    # than the turn it waits on. Only the caller thread is counted; the worker
+    # runs on its own thread and its turn is measured separately, because a
+    # worker loop also polls and those polls belong to no particular call. The
+    # first call is discarded because it pays for activation and caller
+    # registration that a steady-state call does not.
+    # @rbs () -> Integer
+    def synchronous_caller_query_count
       reference = CounterActor.ref("sync-queries")
       worker = SolidObjects::Worker.new
       runner = Thread.new { worker.run }
       reference.sync(:increment)
-      queries = count_queries { reference.sync(:increment) }
-      puts "database queries: #{queries} for 1 synchronous call"
+      count_queries { reference.sync(:increment) }
     ensure
       worker&.request_shutdown
       runner&.join(5)
       worker&.stop
     end
 
+    # Subscriptions are process-wide and notifications run on the thread that
+    # issued the query, so counting is scoped to the measuring thread. Without
+    # that, a worker polling in the background inflates the count by however
+    # many times it happened to poll during the window.
     # @rbs () { () -> untyped } -> Integer
     def count_queries
+      measuring = Thread.current
       queries = 0
       subscriber = ActiveSupport::Notifications.subscribe("sql.active_record") do |event|
+        next unless Thread.current.equal?(measuring)
         next if %w[SCHEMA TRANSACTION].include?(event.payload[:name])
         next if event.payload[:cached]
 

docs/benchmarks.md

@@ -43,17 +43,22 @@ scenario used four worker threads.
 
 Query counts are a property of the code rather than the host, so they are
 tracked separately. Re-measured 2026-08-10 against 0.10.0 on SQLite with
-`bundle exec ruby benchmark/query_count.rb`, which reports both and is
-deterministic across runs:
+`bundle exec ruby benchmark/query_count.rb`, which is deterministic across runs:
 
 | Scenario | Queries |
 | --- | ---: |
 | One message turn | 26 |
-| One synchronous call | 53 |
+| The caller of one synchronous call | 49 |
+| One synchronous call, caller plus the turn it waits on | 75 |
 
-Both numbers moved since they were first recorded, in opposite directions: a
-worker turn fell from 29 and a synchronous call rose from 49. The synchronous
-count had no script behind it until now, which is why it drifted unnoticed.
+A worker turn fell from the 29 recorded earlier. The caller count is unchanged
+at 49, and the combined figure is new: a synchronous call is a caller and a
+worker turn, and only the sum says what the database actually serves.
+
+Counting is scoped to the measuring thread. A worker loop polls whether or not
+a call is in flight, so a process-wide count folds however many polls happened
+to land inside the window into the result. That is also why the caller and the
+turn are measured separately rather than by watching both threads at once.
 
 A synchronous call costs far more queries than a worker turn because the caller
 also registers or heartbeats its caller process, claims the activation, and