solid_objects 0.10.1 → 0.10.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 28a727648d2afc1ed0cd5be03fd624617db444bf173b289327d8c69e2a4abf80
-  data.tar.gz: 0f3bb956b7dcda6f993c92d3ce7f24a3ecf93caf0435030fe2e44955eb581c22
+  metadata.gz: 1cd348d089d12af0c4ea20a5f163d58b69f4796e7741ed12038301139396baae
+  data.tar.gz: e31ad3836b5782ee13f3669eef3645114498e7133dd5f8c561105310f4452867
 SHA512:
-  metadata.gz: 6d5ffbb3074eff11b32966560a2ca42dca37dc7c8c9cf1725a9965a40815752379be88f18b6b0b184592931d180f7248d6c01e5344be2b79a29cdde5377ab23f
-  data.tar.gz: ca700bcc8d86a6939c462be3003b0e649c6a2611289b12064dda9d0f6e3f844cc332e479b355b248e0a97c9073e537b1b99a8ae0cfd7ac454b170bd03bbd9a71
+  metadata.gz: 470ca38a3faacd28a05a8f3cd020a353a1a20a9717aad29ec7c0f6cb9be6efbb6e44ef96abcc5a12c2b151b112cdbda47df73da361a94a26ff275bb0dd7d966b
+  data.tar.gz: 874fa30b34175212a24ecdc115e4fd187c40f46c0e55ff62def214f5b350a54997b738f37a86991a9c032f7e1b7ec017613aa0cebaa6378c90aa0c02d6457fb5

data/CHANGELOG.md

@@ -1,5 +1,23 @@
 # Changelog
 
+## 0.10.2 - 2026-08-10
+
+- Load the mailbox when the gem is required. `SolidObjects::Mailbox` was
+  reachable only through the caller path, which loads it as a side effect of
+  `SolidObjects.client`. The reminder scheduler and the effect executor enqueue
+  through it directly and run in `solid_objects start`, a process that never
+  calls the client, so both raised
+  `NameError: uninitialized constant SolidObjects::ReminderScheduler::Mailbox`.
+  Reminders never fired and effect result messages never delivered, while the
+  supervisor replaced the dying role over and over. Nothing caught it because
+  every test process has already loaded the constant through some other path.
+- Add a load contract test that asks a fresh process what `require
+  "solid_objects"` actually defines, and fails when a file stops being loaded
+  unless it is listed as deliberately deferred with a reason. This is the class
+  of bug that only appears in the standalone worker.
+- Run a due reminder through a real `solid_objects start` worker in the test
+  suite, rather than only in process.
+
 ## 0.10.1 - 2026-08-10
 
 - Support Trilogy. Adapter selection matched the client name rather than the

data/docs/roadmap.md

@@ -18,7 +18,11 @@
   status, which works on all three adapters; a future version may add narrow
   ready/claimed membership tables for very large outboxes, as messages already
   have
-- One-shot and recurring reminders with `:latest` or `:all` catch-up
+- One-shot and recurring reminders with `:latest` or `:all` catch-up, exercised
+  through a real `solid_objects start` worker as well as in process. They were
+  listed here while broken in that worker: the scheduler reached a constant the
+  caller path happened to load, so reminders never fired in production and
+  every in-process test still passed
 - Durable observable invalidations, scalar Turbo replacement, keyed ERB
   components, signed component locals, and authorized replace or morph refresh
 - Batched component refreshes: components sharing a signed `batch:` collapse to

data/lib/solid_objects/version.rb

@@ -1,5 +1,5 @@
 # rbs_inline: enabled
 
 module SolidObjects
-  VERSION = "0.10.1"
+  VERSION = "0.10.2"
 end

data/lib/solid_objects.rb

@@ -55,6 +55,11 @@ require "solid_objects/effect_registry"
 require "solid_objects/commit_action_registry"
 require "solid_objects/lease"
 require "solid_objects/lease_renewer"
+# The reminder scheduler and the effect executor enqueue through the mailbox,
+# and both run in the standalone worker where nothing else has loaded it. It
+# was reachable only through the caller path, so requiring the gem was not
+# enough to run a role that uses it.
+require "solid_objects/mailbox"
 require "solid_objects/worker"
 require "solid_objects/effect_executor"
 require "solid_objects/reminder_scheduler"

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: solid_objects
 version: !ruby/object:Gem::Version
-  version: 0.10.1
+  version: 0.10.2
 platform: ruby
 authors:
 - Lucas Carlson