solid_objects 0.1.0 → 0.2.0

data/docs/architecture.md

@@ -58,9 +58,11 @@ The registry maps a stable persisted actor type string to a Ruby actor class. Re
 
 A reference contains actor type and normalized actor ID. It is cheap,
 serializable as data, and does not imply an active Ruby object. Declared
-message methods delegate to `tell`; declared query and attribute methods
-delegate to `ask`. `destroy` is a reserved synchronous reference operation.
-All three paths authorize through the client.
+message, query, and attribute methods use synchronous caller-assisted
+invocation. `sync` provides the same behavior for a dynamic operation name,
+while `async` only durably enqueues a message and returns its reference.
+`destroy` is a reserved synchronous reference operation. Every path authorizes
+through the client.
 
 ### Client and mailbox
 
@@ -73,10 +75,13 @@ Message execution state is table membership, not a status column. The durable me
 An activation lease is stored on the actor instance:
 
 - Owner process UUID
+- Unique activation token
 - Database-time expiration
 - Monotonic generation
 
-Acquisition and renewal are short database writes. Generation is the fencing token used by every state commit.
+Acquisition and renewal are short database writes. A fresh activation token
+distinguishes concurrent activations owned by the same process. Generation is
+the monotonic fencing token used by every state commit.
 
 ### Activation
 
@@ -140,9 +145,10 @@ end
 `attribute` creates actor instance readers and writers and an ordered read query.
 Public instance methods declared on the actor are messages. Declare helpers as
 private or protected. Messages and queries are exposed as methods on a
-reference: message methods delegate to `tell`, while query and attribute
-methods delegate to `ask`. Returned state snapshots are deeply frozen. The
-explicit `message` DSL remains available for dynamic definitions.
+reference through the same synchronous caller-assisted path. Returned state
+snapshots are deeply frozen. Use `async` for durable fire-and-forget delivery
+and `sync` for dynamic operation names. The explicit `message` DSL remains
+available for dynamic definitions.
 
 `message` and `query` both execute as durable mailbox turns. A query may not
 mutate state. The executor detects query mutation and fails the message. An
@@ -234,7 +240,7 @@ Before actor code:
 
 1. Renew if the lease would expire before the next renewal window.
 2. Load the earliest nonterminal mailbox sequence.
-3. Atomically move its ready membership to claimed membership for the current owner and generation and increment the durable attempt counter.
+3. Atomically move its ready membership to claimed membership for the current owner, activation token, and generation and increment the durable attempt counter.
 4. Set the actor's current message context.
 5. Snapshot state and observable values.
 
@@ -248,7 +254,7 @@ Actor code then executes with no open database transaction and no pinned connect
 
 It cannot:
 
-- Call `ask` from actor context
+- Call another actor directly or with `sync` from actor context
 - Perform a synchronous actor-to-actor wait
 - Assume execution happens once
 - Commit actor state directly
@@ -260,8 +266,8 @@ After actor code, the executor validates state and staged data as JSON and compu
 Successful completion uses one database transaction:
 
 1. Lock the instance row.
-2. Verify owner, generation, and an unexpired lease using database time.
-3. Lock the durable message and verify its claimed membership belongs to that owner and generation.
+2. Verify owner, activation token, generation, and an unexpired lease using database time.
+3. Lock the durable message and verify its claimed membership belongs to that owner, activation token, and generation.
 4. Update native JSON state and state version.
 5. Store the completion timestamp and result on the durable message and delete claimed membership.
 6. Insert staged effects.
@@ -319,21 +325,46 @@ The replacement has a higher generation. When the paused worker resumes, its con
 
 The effect can be delivered again. The stable effect ID is the idempotency key. This is why effect handlers must be idempotent.
 
-## Ask
+## Synchronous invocation
 
-`ask` durably enqueues a normal message with a request ID, then waits for the row to become completed, dead-lettered, or timed out. Every waiter re-queries durable rows. The implemented wake-up interface provides same-process signaling, bounded polling, and dependency injection. PostgreSQL `LISTEN/NOTIFY` and optional Redis Pub/Sub are planned adapters.
+A direct actor method or explicit `sync` call durably enqueues a normal mailbox
+message, then tries to claim that actor for the caller process. If successful,
+it drains earlier messages and the target through the same activation and
+executor used by workers. If another process owns the actor, the caller waits
+for the row to become completed, rejected, dead-lettered, destroyed, or timed
+out. Every wait re-queries durable rows. The implemented wake-up interface
+provides same-process signaling, bounded polling, and dependency injection.
+PostgreSQL `LISTEN/NOTIFY` and optional Redis Pub/Sub are planned adapters.
 
-With a healthy cross-process wake-up adapter, the coordination-overhead target from enqueue or completion commit to the confirming query is p99 at or below 100 milliseconds. End-to-end latency also includes mailbox queueing and handler execution. Polling-only deployments can pay the configured interval on both the worker and result legs, so polling-only `ask` is for background callers, scripts, and control paths rather than latency-sensitive Rails request handlers.
+The normal path does not wait for a worker polling interval because the caller
+assists execution immediately. End-to-end latency still includes earlier
+mailbox work, handler execution, and database commits. When another process
+owns the actor, a healthy cross-process wake-up adapter targets p99 coordination
+overhead at or below 100 milliseconds; polling fallback can pay up to
+`sync_polling_interval` between observations.
 
 Caller timeout:
 
-- Raises `SolidObjects::AskTimeout`.
+- Raises `SolidObjects::SyncTimeout`.
 - Does not cancel or delete the message.
 - Does not prevent later execution.
 - Leaves the result available until retention cleanup.
 
 The durable row remains after timeout and can be inspected directly by message ID. A public request-ID lookup and bounded retention commands are not yet implemented.
 
+`async` performs the same durable enqueue without caller assistance or result
+waiting and immediately returns a `MessageReference`. Runtime workers process
+it normally.
+
+## Domain rejection
+
+Actor code can call `reject` for a validation or business-rule outcome that
+must not retry. The executor restores pre-turn state, discards staged intents,
+stores the structured rejection, completes the claimed membership, and
+continues with the next sequence in one fenced transaction. Synchronous callers
+receive `SolidObjects::Rejected`. A rejection is neither an exception retry nor
+a dead letter.
+
 ## Effects and actor-to-actor delivery
 
 `emit` creates a staged effect:
@@ -380,7 +411,7 @@ Solid Objects persists each occurrence by its mailbox row. Unlike Orleans remind
 
 Durable reminders are alarms, and an alarm can be lost at the application level even while the database and actor state remain healthy. A reminder callback may dead-letter, a handler may fail to schedule its successor, or a signup/configuration path may never enqueue the first message. Unlike a periodic full sweep, a self-scheduling actor can then remain silently inert forever.
 
-Applications with self-scheduling actors should run a lower-frequency reconciliation job. The reconciler may read actor state and report drift, but it never writes actor state directly. Every repair is a normal authorized `tell`, so the actor decides whether the transition is still necessary and all ordering, lease, fencing, and audit rules remain intact.
+Applications with self-scheduling actors should run a lower-frequency reconciliation job. The reconciler may read actor state and report drift, but it never writes actor state directly. Every repair is a normal authorized `async` invocation, so the actor decides whether the transition is still necessary and all ordering, lease, fencing, and audit rules remain intact.
 
 `SolidObjects::Instance` exposes batchable read relations:
 
@@ -392,7 +423,7 @@ The expected drift categories are actors with a lost alarm, missing actors for l
 
 Bulk repair updates to `solid_objects_instances` are forbidden. They bypass activation ownership and fencing and can overwrite a concurrently committed actor state. Direct reads are observational; writes go through actor messages.
 
-Large repairs use `tell(..., available_at:)` to spread work over an application-defined dispatch window. The durable message records the requested availability and ready membership drives the hot polling query. This prevents reconciliation from flooding mailboxes and starving normal traffic.
+Large repairs use `async(..., available_at:)` to spread work over an application-defined dispatch window. The durable message records the requested availability and ready membership drives the hot polling query. This prevents reconciliation from flooding mailboxes and starving normal traffic.
 
 ## Realtime integration
 
@@ -589,8 +620,8 @@ All backends use unique identity and sequence constraints, short transactions, a
 ## Answers to required correctness questions
 
 1. **How is a per-actor sequence allocated safely?** The instance row is created uniquely, locked in the enqueue transaction, incremented, and the message inserted under a unique actor/sequence index.
-2. **How is one valid activation guaranteed?** Claim atomically changes owner and increments generation on one locked instance row. Only the matching unexpired owner/generation can commit.
-3. **How are stale writes rejected?** Every commit verifies owner, generation, and database-time expiration.
+2. **How is one valid activation guaranteed?** Claim atomically changes owner, creates a unique activation token, and increments generation on one locked instance row. Only the matching unexpired owner/token/generation can commit.
+3. **How are stale writes rejected?** Every commit verifies owner, activation token, generation, and database-time expiration.
 4. **What if a worker dies during execution?** No actor transaction remains open. After lease expiry, a new generation retries the uncommitted message.
 5. **What if it dies after commit but before acknowledgement?** Completion and state are already durable, so the new activation skips that message.
 6. **How are external effects retry-safe?** Effects are inserted atomically into an outbox and use a stable effect ID for handler idempotency.
@@ -601,7 +632,7 @@ All backends use unique identity and sequence constraints, short transactions, a
 11. **How are actors deactivated?** Idle cache timeout or eviction, best-effort hook, conditional lease release.
 12. **How are leases renewed?** Conditional database update by instance, owner, generation, and unexpired lease.
 13. **How does graceful shutdown work?** Stop claims, finish current turn within timeout, release cached leases, stop heartbeat, mark process stopped.
-14. **How does ask work across processes?** A wake-up adapter prompts a durable result query; periodic polling remains the fallback. Polling-only use is scoped to non-latency-sensitive callers.
+14. **How does synchronous invocation work across processes?** The caller first tries to claim and execute the actor locally. If another process owns it, a wake-up adapter prompts a durable result query and bounded polling remains the fallback.
 15. **What happens after caller timeout?** The durable message continues and its eventual result remains on the message row.
 16. **How are results cleaned up?** The schema has cleanup indexes, but bounded retention tooling is not implemented yet.
 17. **How are large mailboxes managed?** The implemented controls are the per-actor mailbox cap, payload caps, and fair activation yields; rate and global admission controls remain roadmap work.

data/docs/benchmarks.md

@@ -5,21 +5,21 @@ They include the runtime's Active Record and database query overhead and will
 vary with hardware, schema size, connection pools, durability settings, and
 contention.
 
-Measured 2026-08-05 on an Apple M5 with 24 GB RAM, Ruby 4.0.5, Rails 8.1.3.1,
+Measured 2026-08-06 on an Apple M5 with 24 GB RAM, Ruby 4.0.5, Rails 8.1.3.1,
 and SQLite 3.51.0. Each throughput scenario used 200 operations; the concurrent
 scenario used four worker threads.
 
 | Scenario | Result |
 | --- | ---: |
-| Enqueue, one actor | 522.4 messages/s |
-| Claim, 200 actors | 1,009.3 claims/s |
-| Process, 40 actors round-robin | 548.7 messages/s |
-| Process, 200 cold actors | 119.5 messages/s |
-| Process, one hot actor | 729.1 messages/s |
-| Process, four workers | 568.2 messages/s |
-| Ask latency | p50 9.2 ms, p95 15.6 ms, p99 53.7 ms |
+| Enqueue, one actor | 629.2 messages/s |
+| Claim, 200 actors | 1,038.4 claims/s |
+| Process, 40 actors round-robin | 548.1 messages/s |
+| Process, 200 cold actors | 121.5 messages/s |
+| Process, one hot actor | 726.4 messages/s |
+| Process, four workers | 556.5 messages/s |
+| Synchronous latency | p50 1.8 ms, p95 25.6 ms, p99 156.2 ms |
 | Activation reuse | 98.0%, four activations for 200 messages |
-| Queries for one message turn | 28 |
+| Queries for one message turn | 29 |
 
 The scripts and invocation examples are in the
 [development guide](development.md#benchmarks). PostgreSQL and MySQL should be

data/docs/correctness.md

@@ -20,11 +20,14 @@ messages until success or dead-lettering.
 
 ## Ownership and fencing
 
-Claiming an actor writes a process UUID, database-time expiration, and a
-monotonically increasing generation. Every successful or failed message
-finalization locks the instance and checks:
+Claiming an actor writes a process UUID, a unique activation token,
+database-time expiration, and a monotonically increasing generation. The token
+separates concurrent activations in one process; the generation fences every
+older activation. Every successful or failed message finalization locks the
+instance and checks:
 
 - owner UUID matches;
+- activation token matches;
 - generation matches;
 - expiration is still in the future according to database time; and
 - claimed-message membership names the same owner and generation.
@@ -106,13 +109,29 @@ The following are atomic:
 
 Actor Ruby code and external I/O are never inside the actor-state transaction.
 
-## Ask
+## Synchronous invocation
 
-`ask` is a durable message followed by result polling and wake-up hints. Timeout
-does not cancel the message. The current cross-process fallback is polling;
-therefore polling-only ask is not recommended in latency-sensitive HTTP paths.
-Destroying the actor while an `ask` is waiting removes its message, wakes the
-caller, and raises `SolidObjects::ActorDestroyed`.
+A direct reference method or explicit `sync` call durably enqueues an ordinary
+mailbox message. The caller then attempts to claim that actor and execute
+through the same activation, lease renewal, fencing, and executor code used by
+a worker. It drains earlier messages first and returns only the committed
+result. A worker may win the activation instead; the caller then observes the
+durable result through wake-up hints with bounded polling as fallback.
+
+Timeout raises `SolidObjects::SyncTimeout` but does not cancel the message.
+Destroying the actor while a synchronous caller waits removes its message,
+wakes the caller, and raises `SolidObjects::ActorDestroyed`.
+
+`async` performs only the durable enqueue and immediately returns a
+`MessageReference`.
+
+## Domain rejection
+
+`reject` is a terminal domain outcome, not an infrastructure failure. It rolls
+back in-memory state and staged intents, stores a structured rejection on the
+message, removes claimed membership, and lets the next sequence run. It is
+never retried or dead-lettered. The synchronous caller receives
+`SolidObjects::Rejected`; asynchronous callers can inspect the message status.
 
 ## Database dependencies
 

data/docs/database-schema.md

@@ -8,8 +8,9 @@ migrations load. No partial indexes are used.
 ### `instances`
 
 One row per `(actor_type, actor_id)`. Stores JSON state, state version,
-next-message sequence, activation owner/expiration/generation, pause state, and
-lifecycle timestamps.
+next-message sequence, activation owner/token/expiration/generation, pause
+state, and lifecycle timestamps. The owner/token pairing is constrained so one
+process row cannot make two concurrent activations appear identical.
 
 Deleting an instance is the actor-incarnation boundary. Foreign keys cascade
 the delete through messages, ready and claimed memberships, reminders, effects,
@@ -27,14 +28,17 @@ Indexes:
 
 Durable immutable invocation identity and arguments plus sequence, attempt
 count, request/idempotency IDs, result/error, requested availability, and
-execution timestamps. It intentionally has no status column.
+execution timestamps. A terminal domain rejection stores a structured
+code/message/details document and rejection time. The table intentionally has
+no status column.
 
 Indexes:
 
 - unique instance/sequence and actor identity/sequence: mailbox order;
-- unique request ID: ask lookup;
+- unique request ID: synchronous result lookup;
 - unique instance/idempotency key: deduplicated enqueue;
-- completion/ID: bounded retention cleanup.
+- completion/ID: bounded retention cleanup;
+- rejection/ID: bounded rejection inspection and cleanup.
 
 ### `ready_messages`
 
@@ -50,7 +54,8 @@ Indexes:
 ### `claimed_messages`
 
 Small hot membership table for one message currently owned by an activation.
-It records process UUID, activation generation, and claim time.
+It records process UUID, unique activation token, activation generation, and
+claim time.
 
 Indexes:
 
@@ -108,4 +113,7 @@ The public `reference.destroy` operation locks the instance row before deleting
 it. Every actor-owned table has a cascading foreign key either directly to the
 instance or through its message row. No application-side bulk delete can leave
 an executable orphan. Process registry rows are not actor-owned and remain
-available for worker lifecycle accounting.
+available for worker lifecycle accounting. Activation-owner foreign keys use
+restrictive deletion so the owner/token check remains enforceable on MySQL;
+runtime deregistration clears leases and claims before a process row can be
+pruned.

data/docs/development.md

@@ -67,8 +67,8 @@ correct change, rerun the focused test, then the complete database matrix.
 ## Benchmarks
 
 Scripts in `benchmark/` cover enqueue, claim, processing, cold actors, a hot
-actor, concurrent actors, ask latency, cache reuse, and query counts. Results
-describe one machine and database configuration; they are not universal
+actor, concurrent actors, synchronous latency, cache reuse, and query counts.
+Results describe one machine and database configuration; they are not universal
 capacity guarantees.
 
 ```bash
@@ -78,7 +78,7 @@ COUNT=500 bundle exec ruby -Ilib benchmark/processing.rb
 COUNT=500 bundle exec ruby -Ilib benchmark/cold_actors.rb
 COUNT=500 bundle exec ruby -Ilib benchmark/hot_actor.rb
 COUNT=500 CONCURRENCY=4 bundle exec ruby -Ilib benchmark/concurrent_actors.rb
-COUNT=100 bundle exec ruby -Ilib benchmark/ask_latency.rb
+COUNT=100 bundle exec ruby -Ilib benchmark/sync_latency.rb
 COUNT=500 bundle exec ruby -Ilib benchmark/activation_cache.rb
 bundle exec ruby -Ilib benchmark/query_count.rb
 ```

data/docs/implementation-plan.md

@@ -161,7 +161,7 @@ Create the seven domain tables plus ready- and claimed-message membership tables
 
 The schema installs in PostgreSQL, MySQL, and SQLite dummy databases and database constraints reject invalid states independently of Rails validations.
 
-## Milestone 3: Durable enqueue, references, tell, and ask
+## Milestone 3: Durable enqueue and invocation modes
 
 ### Files
 
@@ -171,14 +171,15 @@ The schema installs in PostgreSQL, MySQL, and SQLite dummy databases and databas
 - `lib/solid_objects/message_reference.rb`
 - `lib/solid_objects/wake_up.rb`
 - `test/integration/enqueue_test.rb`
-- `test/integration/tell_test.rb`
-- `test/integration/ask_test.rb`
+- `test/integration/enqueue_test.rb`
+- `test/integration/sync_test.rb`
+- `test/integration/synchronous_invocation_test.rb`
 
 ### Public API
 
-- `Reference#tell`
-- `Reference#ask`
-- Method-style message, query, and read-only attribute dispatch
+- `Reference#async`
+- `Reference#sync`
+- Synchronous method-style message, query, and read-only attribute dispatch
 - `MessageReference#id`, `#status`, `#result`
 - Authorization context and hooks
 
@@ -191,8 +192,10 @@ No new tables. Use instance sequence and message request/idempotency columns.
 - Per-actor sequence allocation under concurrent connections
 - Independent sequences for different actors
 - Idempotency key deduplication
-- Tell return value
-- Ask success, failure, and timeout
+- Async return value
+- Synchronous success, rejection, failure, and timeout
+- Caller-assisted processing behind earlier asynchronous work
+- Same-actor serialization and different-actor concurrency
 - Mailbox and payload limits
 - Message/query authorization failure
 
@@ -201,12 +204,15 @@ No new tables. Use instance sequence and message request/idempotency columns.
 - Concurrent first enqueue
 - Lock timeout or deadlock
 - Duplicate idempotency key with different payload
-- Ask caller timeout
+- Synchronous caller timeout
 - Oversized payload or mailbox
 
 ### Completion criteria
 
-Messages and ready membership enqueue durably in strict per-actor sequence and `ask` can observe a manually completed result. Polling-only `ask` is documented as unsuitable for latency-sensitive request handlers.
+Messages and ready membership enqueue durably in strict per-actor sequence.
+Direct methods and `sync` claim and execute the actor locally when possible,
+while `async` returns immediately for worker execution. Every path uses the
+same mailbox, lease, fencing, and durable result.
 
 ## Milestone 4: Fenced, runnable vertical slice
 
@@ -236,7 +242,7 @@ No new tables.
 
 ### Tests
 
-- Shopping cart tell and ask
+- Shopping cart synchronous and asynchronous invocation
 - One actor processes messages sequentially
 - Different actors can execute concurrently
 - Lease acquire, renew, expire, and release
@@ -246,7 +252,7 @@ No new tables.
 - State and completion are atomic
 - Basic retry and strict head-of-mailbox blocking
 - Handler-level duplicate-delivery guards
-- Actor-to-actor tell outside actor context
+- Actor-to-actor asynchronous delivery
 
 ### Failure modes
 
@@ -325,7 +331,7 @@ Use the effects table. Add delivery-token or outcome columns only through a migr
 - Stable idempotency context
 - Success/failure outcome messages
 - Transactional actor-to-actor delivery
-- `ask` rejected in actor context
+- Direct and `sync` actor-to-actor calls rejected in actor context
 
 ### Failure modes
 
@@ -464,13 +470,13 @@ No expected changes.
 - Sensitive data in logs
 - Unbounded admin queries
 - Retrying wrong dead letter
-- Cleanup racing with ask waiter
-- Reconciliation code mutating actor state outside `tell`
+- Cleanup racing with a synchronous waiter
+- Reconciliation code mutating actor state outside `async`
 - Reconciliation stampedes without delayed `available_at`
 
 ### Completion criteria
 
-Operators can inspect health and failures without direct SQL, locate lost alarms and orphaned actors, and observe every required transition without raw arguments. Documentation requires reconciliation repairs to use delayed `tell` rather than direct instance updates.
+Operators can inspect health and failures without direct SQL, locate lost alarms and orphaned actors, and observe every required transition without raw arguments. Documentation requires reconciliation repairs to use delayed `async` delivery rather than direct instance updates.
 
 ## Milestone 10: Examples, benchmarks, documentation, and release hardening
 

data/docs/operations.md

@@ -61,7 +61,7 @@ operational task until that roadmap item lands.
 
 Self-scheduling actors need a daily or similarly low-frequency reconciliation
 job because an application-level alarm can be lost. The reconciler reads state
-but sends every repair through `tell`.
+but sends every repair through `async`.
 
 Use:
 
@@ -115,8 +115,8 @@ Alert on:
 
 The schema has cleanup indexes, but automatic pruning commands are still
 roadmap work. Until implemented, define application-owned bounded deletes that
-preserve unfinished messages, dead letters under investigation, and ask results
-for the promised lookup period.
+preserve unfinished messages, dead letters under investigation, and synchronous
+results for the promised lookup period.
 
 Back up actor tables with the same consistency guarantees as application data.
 Restoring only instances without their mailboxes/outboxes, or vice versa, can

data/docs/research/solid_queue.md

@@ -82,7 +82,8 @@ The equivalent thin public surface is:
 
 - `SolidObjects::Actor` for definitions.
 - `ActorClass.ref(actor_id)` for logical addressing.
-- `SolidObjects::Reference#tell` and `#ask` for invocation.
+- Direct methods and `SolidObjects::Reference#sync` for request/response
+  invocation, plus `#async` for durable enqueue.
 - Explicit helpers for reminders, effects, observables, and lifecycle hooks.
 
 Mailbox rows, leases, worker records, and outboxes remain internal. Public message and dead-letter references should expose identifiers and safe inspection methods without leaking Active Record mutation APIs.

data/docs/roadmap.md

@@ -4,11 +4,14 @@
 
 - Rails engine, install generator, migration, and CLI
 - Explicit actor registry, references, JSON state, and state migrations
+- Direct synchronous RPC, explicit `sync`, and durable `async`
 - Durable message history plus ready/claimed membership tables
 - Concurrent sequence allocation and actor creation
-- Activation leases, renewal, generations, and fenced commits
+- Activation leases, renewal, unique activation tokens, generations, and
+  fenced commits
 - Bounded activation passes, idle cache, hot-actor yield, and process records
-- At-least-once retries, strict poison ordering, dead letters, and tail retry
+- At-least-once retries, terminal domain rejection, strict poison ordering,
+  dead letters, and tail retry
 - Transactional effects with success/failure actor messages
 - Actor-to-actor asynchronous outbox delivery
 - One-shot and recurring reminders with `:latest` or `:all` catch-up

data/docs/security.md

@@ -9,8 +9,10 @@ application supplies the authenticated request or connection as
 
 Method-style reference calls do not bypass these hooks. Public instance methods
 declared on an actor are part of its remotely addressable message surface and
-delegate to the authorized `tell` path. Keep implementation helpers private or
-protected. Query and attribute methods delegate to the authorized `ask` path.
+delegate to the authorized synchronous invocation path. Keep implementation
+helpers private or protected. Query and attribute methods use the separate
+query authorization policy. Explicit `async` message delivery uses the same
+message authorization policy as direct calls.
 `reference.destroy` delegates to `authorize_destroy` before checking whether
 the actor exists, so denial does not reveal actor existence.
 

data/lib/solid_objects/activation.rb

@@ -31,26 +31,12 @@ module SolidObjects
 
     # @rbs () -> Integer
     def drain
-      processed_count = 0
-      started_at = monotonic_now
-      @pass_exhausted = false
-
-      loop do
-        if processed_count >= SolidObjects.configuration.max_messages_per_activation_pass ||
-            monotonic_now - started_at >= SolidObjects.configuration.max_activation_duration
-          @pass_exhausted = true
-          break
-        end
-
-        message = claim_next_message
-        break unless message
-
-        Executor.new(activation: self, message:).call
-        processed_count += 1
-        @last_used_at = monotonic_now
-      end
+      drain_messages
+    end
 
-      processed_count
+    # @rbs (message_id: Integer, deadline: Float) -> Integer
+    def drain_until(message_id:, deadline:)
+      drain_messages(message_id:, deadline:)
     end
 
     # @rbs () -> bool
@@ -60,6 +46,7 @@ module SolidObjects
         ClaimedMessage.where(
           instance_id: lease.instance_id,
           process_id: lease.owner_id,
+          activation_token: lease.activation_token,
           activation_generation: lease.generation
         ).exists?
     end
@@ -113,6 +100,33 @@ module SolidObjects
 
     attr_reader :actor_class
 
+    # @rbs (?message_id: Integer?, ?deadline: Float?) -> Integer
+    def drain_messages(message_id: nil, deadline: nil)
+      processed_count = 0
+      started_at = monotonic_now
+      @pass_exhausted = false
+
+      loop do
+        break if deadline && monotonic_now >= deadline
+
+        if processed_count >= SolidObjects.configuration.max_messages_per_activation_pass ||
+            monotonic_now - started_at >= SolidObjects.configuration.max_activation_duration
+          @pass_exhausted = true
+          break
+        end
+
+        message = claim_next_message
+        break unless message
+
+        Executor.new(activation: self, message:).call
+        processed_count += 1
+        @last_used_at = monotonic_now
+        break if message.id == message_id
+      end
+
+      processed_count
+    end
+
     # @rbs (Instance) -> Actor
     def build_actor(instance)
       state_data = actor_class.definition.migrate_state(instance.state_version, instance.state)
@@ -145,6 +159,7 @@ module SolidObjects
           message:,
           instance:,
           process_id: lease.owner_id,
+          activation_token: lease.activation_token,
           activation_generation: lease.generation,
           claimed_at: now
         )
@@ -161,6 +176,7 @@ module SolidObjects
         .first
       return unless claimed_message
       return if claimed_message.process_id == lease.owner_id &&
+        claimed_message.activation_token == lease.activation_token &&
         claimed_message.activation_generation == lease.generation
 
       message = claimed_message.message

data/lib/solid_objects/activation_manager.rb

@@ -13,17 +13,37 @@ module SolidObjects
 
     # @rbs () -> Activation?
     def claim_next
+      claim_from(candidate_instance_ids(database_adapter.database_now))
+    end
+
+    # @rbs (instance_id: Integer) -> Activation?
+    def claim(instance_id:)
+      claim_from([ instance_id ])
+    end
+
+    private
+
+    attr_reader :owner_id, :database_adapter
+
+    # @rbs (Array[Integer]) -> Activation?
+    def claim_from(instance_ids)
       lease = database_adapter.transaction do
         now = database_adapter.database_now
         claimed_lease = nil
-        candidate_instance_ids(now).each do |instance_id|
+        instance_ids.each do |instance_id|
           instance = database_adapter.lock_candidates(
             Instance.where(id: instance_id)
           ).first
           next unless instance
           next unless claimable?(instance, now)
 
-          claimed_lease = Lease.claim(instance:, owner_id:, now:, database_adapter:)
+          claimed_lease = Lease.claim(
+            instance:,
+            owner_id:,
+            activation_token: SecureRandom.uuid,
+            now:,
+            database_adapter:
+          )
           break if claimed_lease
         end
         claimed_lease
@@ -42,10 +62,6 @@ module SolidObjects
       raise
     end
 
-    private
-
-    attr_reader :owner_id, :database_adapter
-
     # @rbs (Time) -> Array[Integer]
     def candidate_instance_ids(now)
       (ready_instance_ids(now) + claimed_instance_ids(now)).uniq