pgbus 0.18.0 → 0.18.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 5ecd5c93d6e4cd514d0733f95f5f064d84d16393e104047e4ce4920c69926939
-  data.tar.gz: ef893f0ded94410bb8759ff30486c7fbd2ea0abe2ad156b47b96c4e600f31e18
+  metadata.gz: e64af488e23381da4f7685e20a194addef033c1fb175fa64b1de7b169dc67996
+  data.tar.gz: b98a831339953b46a44e0a37468277d05b8718c3ac3fa7d7ee82d8857f78928f
 SHA512:
-  metadata.gz: 04d7ddc5cfa15881f2911ed7a88f559ed8b037eaf734ae7cee41cdde4ebca917e537a84f758b439477827e5824d8eb311fe1d373c4c511a859cae01a0bd3faba
-  data.tar.gz: 339b3a25781d0342b0414022cabe303c9f5b45332ee1b4d4cb83cf55c3635bec0a80cd528c794c6425eb0b58db7ccbe5a5a49a95854ba72aa41576f1619695df
+  metadata.gz: f1a4d7d62a2c9a7a2767896246e20ec36ba3b5626ef0d45bb4b2cdc7efb50b14b99e57a848167db58a8d49e35ae5b7b8a367959a66044aa350b8eda7716afa05
+  data.tar.gz: f39f4dc967ea079dab0b1d7536bbc6effb9bd044f310a40e0fc1e4a988c03f1b104da4ab12f5c2eed515d67e805f6abc2e2d0944afdf8d77c4025436080b3a83

data/CHANGELOG.md

@@ -56,6 +56,8 @@
 
 ### Fixed
 
+- **A draining worker no longer strands its read-ahead claims.** The worker loop checked `can_process?` once to decide whether to return buffered claims, then read the lifecycle again to decide whether to exit. A drain (`graceful_shutdown`) or stop (`immediate_shutdown`) from another thread that landed between the two reads let the loop exit with the buffer still full (a pause does not exit the loop, so its claims go back on the next step), so those messages stayed invisible until their visibility timeout instead of going straight back to the queue (`vt: 0`). The worker now returns whatever is still buffered after the loop, however it exits. This was the intermittent `worker_read_ahead_spec.rb:217` failure (about 1 run in 20). Refs #486.
+
 - **`pgbus:connected` now fires only once the connection is registered and its presence join has run.** `StreamApp` wrote the frame at hijack time, before the streamer's dispatcher had handled the connect, so a page that acted on its connection id as soon as it heard the event — `Pgbus.stream(x).presence.set_state(connection_id:)` from an action, for instance — found no row (`set_state` returned nil) and had to retry. The dispatcher now writes the frame at the end of the connect, after the archive replay, `registry.register` and the presence join attempt (a stream without presence, or a member resolver that returns nil, has no seat to join; a join that raises is logged and the frame still follows), through the connection's mutex-serialised writer (`Connection#write_connected` / `FalconConnection#write_connected`). The event name, its `connectionId` payload and the element's `connection-id` attribute are unchanged; listeners hear it after any replayed frames instead of before them, and a connection that dies during the replay never gets one. A repeated disconnect for an already-unregistered connection no longer records a second `disconnect` stream stat. Closes #521.
 
 - **A closed tab leaves its presence seat at once, not on the next heartbeat.** The server never reads a hijacked SSE socket after the request, so a client that went away was noticed only when a heartbeat write failed: up to `streams_heartbeat_interval` later (15 s by default), and often a beat later still, because the first write after the client's FIN succeeds. Every viewer of a presence roster kept the closed tab for that long. A new `PeerCloseWatcher` thread per streamer waits on every live hijacked socket with `IO.select` and probes a readable one with a non-blocking read: EOF or a reset marks the connection dead, closes it and posts the same `DisconnectMessage` the heartbeat posts, so the seat leaves (and `streams_presence_on_change` fires once) within milliseconds on Puma and on Falcon's default hijack path; a connection closed within its first `streams_peer_close_interval` after opening is noticed within that interval. A TLS client that vanishes without close_notify (OpenSSL's or Puma MiniSSL's SSL error on read) counts as closed, the probe skips a socket while a write holds its mutex, and `#stop` wakes the select through a self-pipe so shutdown does not wait out the interval. The client sends nothing after its request, so a readable socket means a close; stray bytes are read and discarded. Falcon's experimental streaming-body path has no socket and keeps the heartbeat. New setting `streams_peer_close_interval` (1.0 s by default): how long a newly opened connection waits to join the watched set; `nil` turns the watcher off. Closes #519.

data/lib/pgbus/process/worker.rb

@@ -210,6 +210,11 @@ module Pgbus
           @wake_signal.wait(timeout: config.polling_interval) if @lifecycle.draining? || @lifecycle.paused?
         end
 
+        # The lifecycle can change on another thread between the
+        # return_claims check and the breaks above, so a loop that exits with
+        # the state it never returned claims for would strand them until their
+        # visibility timeout. Nothing buffered outlives the loop.
+        return_claims
         shutdown
       end
 

data/lib/pgbus/version.rb

@@ -1,5 +1,5 @@
 # frozen_string_literal: true
 
 module Pgbus
-  VERSION = "0.18.0"
+  VERSION = "0.18.1"
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: pgbus
 version: !ruby/object:Gem::Version
-  version: 0.18.0
+  version: 0.18.1
 platform: ruby
 authors:
 - Mikael Henriksson