This page documents the API for inspecting and interrogating Solid::Result objects returned by processes. It covers predicate methods, dynamic type checking, data access patterns, and Ruby 3.1+ pattern matching syntax for handling process outcomes.
All result inspection capabilities are provided by the solid-result gem, which Solid::Process depends on. See page 2.3 for result types and page 3.1 for the execution lifecycle.
Solid::Result provides several predicate methods for checking result status and type. These methods return boolean values and are the primary API for conditional logic based on process outcomes.
Title: Basic Result Status Predicates
| Method | Description | Return Type |
|---|---|---|
result.success? | Returns true if result is a Solid::Success | Boolean |
result.failure? | Returns true if result is a Solid::Failure | Boolean |
Sources: test/solid/process/result_test.rb28-35 README.md136-138
Results have a :type attribute that identifies the specific outcome. Multiple predicate methods allow type checking:
Title: Result Type Checking Methods
| Method | Description | Example |
|---|---|---|
result.type | Returns the type symbol | :user_created |
result.is?(:type) | Checks if type matches the given symbol | result.is?(:user_created) |
result.type?(:type) | Alias for is? | result.type?(:user_created) |
result.success?(:type) | Checks if result is success AND type matches | result.success?(:user_created) |
result.failure?(:type) | Checks if result is failure AND type matches | result.failure?(:invalid_input) |
Sources: test/solid/process/result_test.rb32-35 test/solid/process/dependencies/result_test.rb54-58
Results respond to dynamic predicate methods based on their type. A result with type :user_created will respond to result.user_created?, returning true.
Title: Dynamic Predicate Method Resolution
| Result Type | Dynamic Predicate | Returns |
|---|---|---|
:user_created | .user_created? | true |
:email_already_taken | .email_already_taken? | true |
:invalid_input | .invalid_input? | true |
:invalid_dependencies | .invalid_dependencies? | true |
Dynamic predicates return true if the result's type matches the method name (minus the ?), otherwise false. Calling an undefined predicate on a result that doesn't match will return false rather than raising NoMethodError.
Sources: test/solid/process/result_test.rb31-83 test/solid/process/dependencies/result_test.rb27-110
Results carry data in a hash accessible through multiple APIs. The data structure depends on whether the result is a success or failure.
Title: Result Data Access Methods
| Method | Description | Example Return Value |
|---|---|---|
result.value | Returns the entire value hash | {user: <User>} |
result[:key] | Accesses a specific key in the value hash | <User id: 1> |
result.value.fetch(:key) | Fetches a key with exception if missing | <User id: 1> |
result.value.keys | Returns array of keys in value hash | [:user] |
Sources: test/solid/process/result_test.rb37-63 test/solid/process/dependencies/result_test.rb33-62 README.md136-138
Different result types carry different data structures:
| Result Type | Value Hash Structure | Accessed Via |
|---|---|---|
:user_created (Success) | {user: <User>} | result[:user] |
:invalid_input (Failure) | {input: <Solid::Input>} | result[:input] |
:invalid_dependencies (Failure) | {dependencies: <Dependencies>} | result[:dependencies] |
:email_already_taken (Failure) | Varies by implementation | result.value |
For :invalid_input failures, the input object includes validation errors accessible via result[:input].errors.
Sources: test/solid/process/result_test.rb61-69 test/solid/process/dependencies/result_test.rb33-94
Results support Ruby's pattern matching syntax (in clauses) for declarative control flow based on result status and type.
Title: Pattern Matching on Solid::Result
Results implement the deconstruct_keys protocol, allowing them to be pattern matched against hash-like patterns. The deconstructed hash includes:
| Key | Type | Description |
|---|---|---|
:success | Boolean | true for success, false for failure |
:type | Symbol | The result type (e.g., :user_created) |
:value | Hash | The data carried by the result |
Matching Success vs Failure:
Matching Specific Types:
Combining Status and Type:
Pattern matching enables extracting specific data from results while checking their type, reducing boilerplate compared to imperative approaches with if/elsif chains.
Sources: Ruby 3.1+ pattern matching protocol, test/solid/process/result_test.rb21-46
Each result has an associated type symbol that identifies the specific outcome. The type is used for routing, logging, and conditional logic.
Title: Result Type Symbol Flow
When creating results in process call methods, the first argument to Success() or Failure() becomes the result's type:
| Result Creation | Type Symbol | Accessed Via |
|---|---|---|
Success(:user_created, ...) | :user_created | result.type |
Failure(:invalid_input, ...) | :invalid_input | result.type |
Failure(:email_already_taken, ...) | :email_already_taken | result.type |
Type symbols should use snake_case and be descriptive of the specific outcome. They are used in predicate methods, pattern matching, and event logging.
Sources: README.md126-128 test/solid/process/result_test.rb34-82
The framework automatically generates failures with specific type symbols in certain scenarios:
| Scenario | Type Symbol | When Generated | Data Included |
|---|---|---|---|
| Input validation fails | :invalid_input | Before call method executes | {input: <Solid::Input>} |
| Dependencies validation fails | :invalid_dependencies | Before call method executes | {dependencies: <Dependencies>} |
These framework-defined types are checked before the process's call method runs. If either validation fails, the call method is never executed and the failure is returned immediately.
Sources: test/solid/process/result_test.rb56-60 test/solid/process/dependencies/result_test.rb27-40 page 3.1 (Caller module)
Pattern matching and inspection enable systematic debugging approaches for process failures and unexpected behaviors.
Pattern matching enables clean separation of business logic based on process outcomes:
Sources: Process execution patterns, Error handling mechanisms
Pattern matching works seamlessly with the framework's event logging system to provide comprehensive debugging capabilities.
The combination of pattern matching and event logging provides:
Sources: Event logging system architecture, Observability patterns
Refresh this wiki