 |
VOOZH | about |
|
VOOZH | about |
This document covers three critical runtime configuration files in the workbench environment: logging, queue, and exception handling. These configurations control how the application logs messages, processes background jobs, and handles errors during test execution.
For general configuration concepts, see Configuration Management. For application-level configuration like environment and debug settings, see Application Configuration. For database configuration, see Database Configuration.
The testbench workbench provides three configuration files that manage runtime behavior:
| Configuration File | Purpose | Primary Components |
|---|---|---|
workbench/config/logging.php | Defines logging channels and handlers | Monolog channels, handlers, processors |
workbench/config/queue.php | Configures queue connections and failure handling | Queue drivers, batching, failed job storage |
workbench/config/exceptions.php | Registers exception handlers | HTTP exception handler bindings |
These configurations integrate with Hyperf's and Hypervel's service providers to establish runtime services during test execution.
Sources: workbench/config/logging.php1-27 workbench/config/queue.php1-21 workbench/config/exceptions.php1-11
The workbench/config/logging.php file configures Monolog-based logging channels for the application. This configuration determines where and how log messages are written during test execution.
Sources: workbench/config/logging.php10-26
| Key | Value | Description |
|---|---|---|
default | 'stderr' | Default logging channel name |
channels.null.driver | 'monolog' | Uses Monolog driver for null channel |
channels.null.handler | NullHandler::class | Discards all log messages (useful for silencing logs in tests) |
channels.stderr.driver | 'monolog' | Uses Monolog driver for stderr channel |
channels.stderr.level | env('LOG_LEVEL', 'debug') | Minimum log level (debug, info, notice, warning, error, critical, alert, emergency) |
channels.stderr.handler | StreamHandler::class | Writes logs to a stream |
channels.stderr.formatter | env('LOG_STDERR_FORMATTER') | Optional custom formatter class |
channels.stderr.with.stream | 'php://stderr' | Write logs to standard error output |
channels.stderr.processors | [PsrLogMessageProcessor::class] | Process PSR-3 message placeholders |
The default stderr channel workbench/config/logging.php10 is configured for test execution visibility. All log messages are written to php://stderr workbench/config/logging.php22 using Monolog\Handler\StreamHandler workbench/config/logging.php19
The log level is controlled by the LOG_LEVEL environment variable, defaulting to debug workbench/config/logging.php18 This ensures maximum verbosity during test execution, making it easier to diagnose test failures.
The Monolog\Processor\PsrLogMessageProcessor workbench/config/logging.php24 processes PSR-3 message placeholders like {variable} in log messages, replacing them with actual values from the context array.
The null channel workbench/config/logging.php12-14 uses Monolog\Handler\NullHandler to discard all log messages. This is useful in tests where you want to suppress log output without affecting the test logic.
Sources: workbench/config/logging.php1-27
The workbench/config/queue.php file configures queue connections, job batching, and failed job handling. In the testbench environment, the default queue connection is sync, which executes jobs synchronously, making tests predictable and easier to debug.
Sources: workbench/config/queue.php6-20
| Key | Value | Description |
|---|---|---|
default | env('QUEUE_CONNECTION', 'sync') | Default queue connection name |
connections.sync.driver | 'sync' | Synchronous queue driver (executes jobs immediately) |
batching.database | env('DB_CONNECTION', 'sqlite') | Database connection for job batching |
batching.table | 'job_batches' | Table name for batch metadata |
failed.driver | env('QUEUE_FAILED_DRIVER', 'database-uuids') | Failed job storage driver |
failed.database | env('DB_CONNECTION', 'sqlite') | Database connection for failed jobs |
failed.table | 'failed_jobs' | Table name for failed job records |
The sync connection workbench/config/queue.php8-10 uses a synchronous driver that executes queued jobs immediately in the same process. This behavior is ideal for testing because:
Job batching configuration workbench/config/queue.php12-15 specifies where batch metadata is stored. Batches allow you to dispatch multiple jobs as a group and track their collective progress.
The job_batches table stores information about:
Failed job configuration workbench/config/queue.php16-20 determines how jobs that throw exceptions are recorded. The database-uuids driver stores failed jobs in the failed_jobs table with UUID identifiers.
Each failed job record includes:
Sources: workbench/config/queue.php1-21
The workbench/config/exceptions.php file registers exception handlers that process uncaught exceptions during application execution. The testbench uses a custom ExceptionHandler class that can be extended for package-specific error handling logic.
Sources: workbench/config/exceptions.php6-10
| Key | Value | Description |
|---|---|---|
handler.http | [Workbench\App\Exceptions\ExceptionHandler::class] | Array of HTTP exception handlers |
The handler.http configuration workbench/config/exceptions.php7-9 registers the Workbench\App\Exceptions\ExceptionHandler class as the primary HTTP exception handler. This class is responsible for:
The handler array syntax allows multiple exception handlers to be registered. Hyperf's exception dispatcher will call each handler in order until one returns a response.
Sources: workbench/config/exceptions.php1-11
The three configuration files integrate seamlessly with the TestCase lifecycle. When TestCase::setUp() creates the application instance, these configurations are loaded and used to initialize runtime services.
Sources: workbench/config/logging.php1-27 workbench/config/queue.php1-21 workbench/config/exceptions.php1-11
All three configuration files support environment variables for runtime customization:
| Configuration | Environment Variable | Default | Purpose |
|---|---|---|---|
| Logging | LOG_LEVEL | 'debug' | Minimum log level for stderr channel |
| Logging | LOG_STDERR_FORMATTER | null | Custom log formatter class |
| Queue | QUEUE_CONNECTION | 'sync' | Default queue connection |
| Queue | QUEUE_FAILED_DRIVER | 'database-uuids' | Failed job storage driver |
| Queue | DB_CONNECTION | 'sqlite' | Database for batching and failed jobs |
These environment variables can be set in testbench.yaml or via the defineEnvironment() method in tests.
Tests can customize these configurations using the defineEnvironment() method provided by the TestCase base class. For details on the defineEnvironment() hook, see Reloading and Environment Management.
Sources: workbench/config/logging.php18-20 workbench/config/queue.php6-18
The three configuration files work together to establish a complete runtime environment:
Queue → Database: Queue batching and failed jobs both use the database connection specified in queue.php workbench/config/queue.php13-18
Exception → Logging: Exception handlers typically log error details using the logging configuration
Queue → Logging: Failed queue jobs are logged before being stored in the database
All → Environment: All three configurations support environment variable customization for test flexibility
Sources: workbench/config/logging.php1-27 workbench/config/queue.php1-21 workbench/config/exceptions.php1-11
The three configuration files provide essential runtime services for the testbench environment:
stderr channel for test visibility and a null channel for silencing logsThese configurations integrate with Hypervel's service providers during application bootstrapping, making logging, queuing, and exception handling services available throughout test execution. Tests can customize these configurations using the defineEnvironment() method for scenario-specific behavior.
Sources: workbench/config/logging.php1-27 workbench/config/queue.php1-21 workbench/config/exceptions.php1-11
Refresh this wiki