phlex-reactive 0.13.1 → 0.13.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: '049bef601e70264a857668de2ad7766f9b4edae020ded0844d2f5efacdc0607d'
-  data.tar.gz: 1293bfd5f14ef03fa1889444c662846d4f1129155e1b9ea458b48529a7644b3b
+  metadata.gz: cb580ca60e8e64b7857e665f34e5311e35f66c8aa4348135c61286456b06649f
+  data.tar.gz: fb25bb13bd78f0923f6a7a3c5ea383101cca16eaf9b808607e074c49dbbaa583
 SHA512:
-  metadata.gz: d3fe07e736d776bdcdc594ef9d4cb3e91aea4c0cf81d6bf9c0f703d5de744e2d60394b79c4bad02c32b98ac04fc99d3b1a6746c88ff8e377e94e259765ddbfec
-  data.tar.gz: eb3c04c9cea640d1c6662e602a77b1b49e4e5e7204cb6c587916440c5695064a84219348127b7282ee83b9dd6e6fa57dced2ca9dd79fd7eba1cb1e33e56d6419
+  metadata.gz: 6d50f4794edea6b74bf4178df8d4a271e947e8bc3eef268d19ba8cb855c3207e87ee9c3bd345a22b3d9192f58510bb00860278c64a59c7f1e1b3478b72af62c0
+  data.tar.gz: '0233287800960c1886865f7df4fe2785237820d16e212b616e1971c879d0a97abd373f55588f2921aef4bd742d8cb053ffb2b560a81862517767dbd883556fac'

data/CHANGELOG.md

@@ -441,6 +441,24 @@ adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
 ### Fixed
 
+- **`reply.pending` kept its settle handle under
+  `enqueue_after_transaction_commit = true` (#254).** The handle was captured in
+  `Phlex::Reactive::Settles#serialize`, which reads a thread-local that lives
+  only for the duration of `reply.pending`'s enqueue block. Under Rails'
+  `ActiveJob::Base.enqueue_after_transaction_commit = true` (the 7.2+
+  recommended setting) `job.enqueue` is deferred to
+  `ActiveRecord.after_all_transactions_commit`, and the endpoint runs every
+  action inside a transaction — so `serialize` always ran AFTER the block had
+  exited. The job serialized with no `phlex_reactive_settle` key,
+  `reactive_settle` was a no-op, and the row sat shimmering until someone
+  reloaded. The handle is now captured when the job INSTANCE is created
+  (`perform_later` → `job_or_instantiate` → `new`), which is synchronous inside
+  the block whether or not the enqueue itself is deferred; `serialize` prefers
+  the captured handle and still falls back to the thread-local. Both the
+  `job:`/`args:` sugar (narrowing per record, so failures stay attributable) and
+  the block form are covered, and a retry re-enqueue keeps its handle. Jobs
+  enqueued outside any `reply.pending` still carry nothing.
+
 - **`rake release` bumps the pin in every tracked lockfile (#247, #253).** Since
   #246 the gem root's `Gemfile.lock` is committed alongside `docs/Gemfile.lock`,
   and both pin `phlex-reactive` by local path — so a version bump that left them

data/README.md

@@ -2591,10 +2591,17 @@ bug). It emits:
 
 - **The handle rides ActiveJob metadata, not `perform`'s arity.** `reply.pending`
   installs it in a thread-local and runs your enqueue inside it;
-  `Settles#serialize` copies it into the job's metadata. So **every other caller
-  of the same job — a nightly sweep, a webhook — keeps working unchanged**, and
-  `reactive_settle` is simply a no-op there. That is load-bearing: these jobs
-  almost always have non-UI callers.
+  `Settles#initialize` captures it onto the job instance and `#serialize` copies
+  it into the job's metadata. So **every other caller of the same job — a
+  nightly sweep, a webhook — keeps working unchanged**, and `reactive_settle` is
+  simply a no-op there. That is load-bearing: these jobs almost always have
+  non-UI callers.
+- **It works under `enqueue_after_transaction_commit = true`.** Rails defers that
+  enqueue to `ActiveRecord.after_all_transactions_commit`, and the endpoint runs
+  your action inside a transaction — so the enqueue (and its `serialize`) happens
+  *after* the block has exited. The capture is therefore at job
+  **instantiation**, which is synchronous inside the block either way. Nothing to
+  configure.
 - **A job that raises still clears the pending state — when it can attribute
   it.** The `job:`/`args:` form enqueues one job per record and narrows each
   job's handle to *that record's* target, so a failure clears exactly its row

data/lib/phlex/reactive/settles.rb

@@ -27,15 +27,19 @@ module Phlex
     # ## The handle rides ActiveJob metadata
     #
     # `reply.pending` installs a Pending::Handle in a thread-local and runs the
-    # caller's enqueue inside it; #serialize below copies it into the job's
-    # metadata, #deserialize restores it. So `perform`'s ARITY IS UNTOUCHED and
-    # every OTHER caller of the same job — a nightly sweep, a webhook — enqueues
-    # it with no handle, in which case `reactive_settle` is a NO-OP that returns
-    # nil. That is load-bearing: these jobs almost always have non-UI callers.
+    # caller's enqueue inside it; #initialize below captures it onto the job
+    # instance, #serialize copies it into the job's metadata, #deserialize
+    # restores it. So `perform`'s ARITY IS UNTOUCHED and every OTHER caller of
+    # the same job — a nightly sweep, a webhook — builds it with no handle, in
+    # which case `reactive_settle` is a NO-OP that returns nil. That is
+    # load-bearing: these jobs almost always have non-UI callers.
     #
-    # (`perform_now` does not round-trip through serialize/deserialize, so it
-    # carries no handle either — which is the correct reading: a synchronous
-    # call has no pending UI waiting on it.)
+    # (A `perform_now` INSIDE the enqueue block does carry the handle, since the
+    # instance is built there — so it settles synchronously. That is the right
+    # reading: `reply.pending` already marked the targets, and something has to
+    # resolve the shimmer. The settle's durable message is replayed from
+    # since-id 0 when the client opens the subscription, so arriving before it
+    # exists is safe.)
     #
     # ## A rolled-back action
     #
@@ -57,12 +61,45 @@ module Phlex
       # shared namespace with every other gem in the app.
       SETTLE_METADATA_KEY = "phlex_reactive_settle"
 
-      # Capture the in-flight settle handle at ENQUEUE time. This is the same
-      # seam pgbus's own ActiveJob::CurrentAttributes integration uses, and it
-      # is adapter-agnostic: it works under :async, :test and :inline as well as
-      # a real backend, which is what app specs need.
+      # Capture the in-flight settle handle at INSTANTIATION (issue #254).
+      #
+      # `serialize` is the seam pgbus's own ActiveJob::CurrentAttributes
+      # integration uses, and it looked like the enqueue-time hook — but under
+      # Rails' `enqueue_after_transaction_commit = true` (the 7.2+ recommended
+      # setting) `job.enqueue` is deferred to
+      # ActiveRecord.after_all_transactions_commit, and the endpoint runs every
+      # action inside a transaction. So the deferral — and with it `serialize` —
+      # always fires AFTER reply.pending's `with_handle` block has exited, with
+      # an empty thread-local: no metadata key, a no-op `reactive_settle`, and a
+      # row left shimmering until someone reloads.
+      #
+      # `new` is the one moment guaranteed to be inside the block:
+      # `perform_later` → `job_or_instantiate` → `new` is synchronous, deferral
+      # or not. Pending#each_with_narrowed_handle narrows the thread-local per
+      # record BEFORE `perform_later`, so the `job:`/`args:` attribution
+      # contract is preserved.
+      def initialize(...)
+        super
+        @reactive_settle_handle ||= Phlex::Reactive::Pending.current_handle
+      end
+
+      # The same capture at ENQUEUE, for an instance built BEFORE the block and
+      # enqueued inside it (`job = MyJob.new(...)` … `reply.pending { job.enqueue }`).
+      # `enqueue` runs synchronously inside the block — it is the deferral it
+      # REGISTERS that runs later — so this is the last moment the thread-local
+      # is visible. `||=` never overwrites: a retry's `retry_job` re-enqueues a
+      # DESERIALIZED instance, which must keep the handle it came back with.
+      def enqueue(...)
+        @reactive_settle_handle ||= Phlex::Reactive::Pending.current_handle
+        super
+      end
+
+      # Prefer the captured handle; the thread-local fallback covers an instance
+      # serialized inside the block without going through either hook. A retry
+      # re-enqueue re-serializes the SAME instance, which keeps its handle — the
+      # right reading: the pending UI is still waiting on this work.
       def serialize
-        handle = Phlex::Reactive::Pending.current_handle
+        handle = @reactive_settle_handle || Phlex::Reactive::Pending.current_handle
         return super unless handle
 
         super.merge(SETTLE_METADATA_KEY => handle.to_h_wire)

data/lib/phlex/reactive/version.rb

@@ -2,6 +2,6 @@
 
 module Phlex
   module Reactive
-    VERSION = "0.13.1"
+    VERSION = "0.13.2"
   end
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: phlex-reactive
 version: !ruby/object:Gem::Version
-  version: 0.13.1
+  version: 0.13.2
 platform: ruby
 authors:
 - Mikael Henriksson