patient_http-solid_queue 1.2.1 → 1.3.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 93637c08faca559001df1b35d597ce4dafa12bc707a333b96f1ba628c6c8255d
-  data.tar.gz: f3a9bda7c95644bcd77ab5504e0e2d00c52ad7e5a9eb2d64a04c840033c4d303
+  metadata.gz: 956dea9ce45835d54dea57c7c15c466c97bda90b90eb6578ed524bfbb443b874
+  data.tar.gz: 27c3a4f28e5633e94dce8d50c065ed8b0e3ad9e51f3b4d538e309438f8438205
 SHA512:
-  metadata.gz: 2f5150d168f6e14bc266fadc8e9553cb393aa6eb0375205468e7404dbc79e41e7bdfb717d47925d6cddd9b5d482b8c697af3a229fb1a652ad08a3393ba55ba07
-  data.tar.gz: a450a384dcfec5176813310d6bcbff694f1df639bd1cec11dc4affbd91c5b4518377c86e41af78b1773523bd7edf52d1f7694e0249a0ef5552d87ce37a58dabe
+  metadata.gz: b4390e68b48dde142b48a6f6602ea39dcc27c49e3dc0bf2713861a7ee7b77f7e553971452b5cd012cf47c9b3363d5d5e14dc834a81a20d91e393425168d2e9f2
+  data.tar.gz: 9ba0f42e0d2d982d328104f12a2ecfdbe027fab5d416560c2abf01891539e552e91a5114dcb9a14ee84bbb7cb7b39837a386302024a344c89961cf4b530e398b

data/ARCHITECTURE.md

@@ -7,7 +7,7 @@ PatientHttp::SolidQueue provides a Solid Queue integration layer for the [patien
 ## Key Design Principles
 
 1. **Non-blocking workers**: Jobs enqueue HTTP requests and quickly return so worker capacity remains available
-2. **Singleton processor per process**: One async I/O processor per worker process handles request concurrency
+2. **Processor per profile**: Each worker process runs one async I/O processor for each configured processor profile. Most applications use only the default processor.
 3. **Callback service pattern**: HTTP results are delivered to callback services via `on_complete` and `on_error`
 4. **Lifecycle integration**: Processor lifecycle is tied to Solid Queue worker start/stop hooks
 5. **Active Job-native task handling**: Request execution, callback jobs, and retries use Active Job semantics
@@ -55,18 +55,19 @@ Background thread that periodically:
 - runs orphan cleanup under a distributed DB lock
 
 ### Configuration
-`PatientHttp::SolidQueue::Configuration` wraps patient_http configuration and adds Solid Queue-specific options such as:
+`PatientHttp::SolidQueue::Configuration` extends patient_http's configuration with Solid Queue-specific options, including:
 - `queue_name`
 - `heartbeat_interval`
 - `orphan_threshold`
-- `payload_store_threshold`
+- `on_retries_exhausted`
+- Named processor profiles
 
 ## Request Lifecycle
 
-1. Application code calls `PatientHttp.get/post/put/patch/delete` (which delegates to the registered Solid Queue handler) or `PatientHttp::SolidQueue.execute` directly.
+1. Application code calls `PatientHttp.get`, `PatientHttp.post`, or another module method (which delegates to the registered Solid Queue handler), or `PatientHttp::SolidQueue.execute` directly.
 2. `RequestJob` is enqueued with serialized request data and callback metadata.
 3. `RequestJob` decrypts/deserializes and calls `RequestExecutor.execute`.
-4. `RequestExecutor` creates an async task and enqueues it on the processor.
+4. `RequestExecutor` creates a `RequestTask` and enqueues it on the processor. The `ProcessorObserver` writes the crash-recovery record before the task is queued.
 5. Processor executes HTTP request asynchronously.
 6. `TaskHandler` enqueues `CallbackJob` with serialized response/error.
 7. `CallbackJob` invokes the callback service method.
@@ -75,8 +76,9 @@ Background thread that periodically:
 
 Each worker process runs:
 - worker threads for regular Active Job execution
-- one async HTTP processor thread
-- one task monitor thread for heartbeat and orphan recovery
+- one async HTTP processor thread for each processor profile
+- completion worker threads for each processor (`completion_threads`, default 2) that decode responses and deliver results
+- one task monitor thread for heartbeat and orphan recovery, shared by all processors
 
 ## State Management
 
@@ -112,7 +114,7 @@ These callbacks support metrics pipelines (StatsD, Prometheus adapters, etc.) an
 
 ## Testing Behavior
 
-In test mode (`PatientHttp.testing?`), request execution runs synchronously to make specs deterministic while keeping the same public API.
+When `RAILS_ENV`, `RACK_ENV`, or `APP_ENV` is `test`, request execution runs synchronously to make specs deterministic while keeping the same public API.
 
 ## Further Reading
 

data/CHANGELOG.md

@@ -4,6 +4,30 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## 1.3.0
+
+### Added
+
+- Install generator: `rails generate patient_http:solid_queue:install` copies the crash-recovery migration and writes a commented `config/initializers/patient_http.rb`. It finds the database Solid Queue uses from `config.solid_queue.connects_to` or `config/database.yml`, writes the migration into that database's migrations path, and prints the matching migrate command, so a multi-database application needs no extra arguments. Pass `--database` to name the database explicitly, or `--skip-initializer` for the migration alone.
+
+### Fixed
+
+- `config.raise_error_responses` applies to requests made with the `PatientHttp` module methods. The module methods pass `nil` when a request doesn't set the option, and `nil` was treated as `false`, so the configured default was ignored. Jobs already enqueued without the option also fall back to the configuration of the processor that runs them.
+- Processor profile overrides for `raise_error_responses` and `payload_store_threshold` apply to requests routed to that profile. Previously the request payload and the callback result used the base configuration's `payload_store_threshold`, whatever processor ran the request.
+- **The shipped migration could not be run.** Its file was named `create_solid_queue_async_http_tables.rb` while the class inside it was `CreatePatientHttpSolidQueueTables`, so `db:migrate` raised `NameError: uninitialized constant CreateSolidQueueAsyncHttpTables` after copying it with `patient_http_solid_queue:install:migrations`. The file is now named to match its class. Applications that worked around this by renaming the file themselves are unaffected.
+
+### Changed
+
+- **No setup call is required.** The request handler is registered when the gem is loaded, so `PatientHttp.get` and the other request methods work in every process that requires the gem, configured or not. Previously `PatientHttp::SolidQueue.configure` or `register_handler` had to be called first or requests raised, which made a missing or unloaded initializer fail at dispatch time.
+- `PatientHttp.configure` and `PatientHttp.configuration` resolve to this gem's configuration, so application code never has to name the integration to configure it. `PatientHttp::SolidQueue.configure` remains equivalent.
+- **`configure` now accumulates instead of replacing.** It yields the one configuration object for the process rather than building a new one each time, so several initializers can each contribute options and a second call no longer discards what an earlier one registered. Code that relied on `configure` resetting the configuration should call `reset_configuration!` first.
+- The configuration is created on first use and published to `PatientHttp` at that moment. Previously it was published only inside `configure`, so a process that started a processor without calling `configure` never received module level secrets registered with `PatientHttp.register_secret`.
+- The request handler stays registered for the life of the process. `stop` no longer unregisters it, so a request made while the process is shutting down is enqueued for another process to run instead of raising.
+- The default `shutdown_timeout` and `logger` are read from Solid Queue when they're used instead of when the configuration is built, so Solid Queue settings made in a later initializer apply.
+- The default `User-Agent` header is `PatientHttp`, the same as the base gem and the Sidekiq integration. It was `SolidQueue-AsyncHttp`. Set `config.user_agent` to keep the old value.
+- `payload_store_threshold` moved to `PatientHttp::Configuration`, next to `register_payload_store`. It is inherited, so `config.payload_store_threshold` is unchanged. `PatientHttp::SolidQueue::Configuration::DEFAULT_PAYLOAD_STORE_THRESHOLD` now points at the base gem's constant and is deprecated.
+- Minimum Ruby version is 3.3.
+
 ## 1.2.1
 
 ### Fixed