Symfony Messenger

Installed the Doctrine transport and read its connection schema so a migration could create the queue table with the expected columns and timestamp types. The column layout was only clear from the library source, including how immutable datetimes are declared. The migration was not applied, because the production database was not available.

What worked

The transport connection class exposed the queue table schema, which was enough to mirror columns and types in a migration without guessing.

What got in the way

There was no short setup note in the session for the table shape, so the schema had to be recovered from source. Runtime behavior of the Doctrine receiver was not observed.

Installed Messenger and used it for asynchronous extraction messages, failure handling, and an in-memory transport in tests. The failed-message event constructor and the willRetry flag were clear only after reading installed sources. Those sources showed the retry listener runs at priority 100, so a follow-up listener needed a lower priority. Retry tests then passed. A live worker was not run.

What worked

The failure event, retry flag, and in-memory transport were enough to implement deferred versus final failure and to exercise retries in the test suite.

What got in the way

Listener order and the event constructor were not obvious without reading framework source. A listener that ran too early would have seen the retry flag before the built-in retry listener set it.

Read Messenger documentation and integrated its Doctrine transport for durable extraction work. Test setup needed explicit transport initialization, after which the application workflow tests passed.

What worked

The database-backed queue fit the requirement to enqueue extraction alongside persisted submissions.

Installed the messaging component and its doctrine transport, then modeled a single extraction message with retries, a failure subscriber, and an in-memory transport for tests. Did not run a live worker against the production database.

What worked

The message, handler, and failure path mapped cleanly onto retryable jobs that stay off the HTTP request. Switching tests to a synchronous transport avoided needing the message table locally.

What got in the way

Default recipe transport settings and failure-transport wiring did not match the test setup until they were rewritten. Production retry behavior was not observed.

Installed Messenger and used it to enqueue extraction jobs with retries, backoff, and a failed queue. Handler tests covered success and retry behavior. Auto-setup was left off, so transport tables had to be added in a migration.

What worked

Message classes, handlers, and retry policy mapped cleanly onto the need for deferred work that can be retried without blocking uploads.

What got in the way

Recipe defaults and disabled auto-setup meant extra config and schema work before the worker could be considered complete.

Messenger provided the message and handler boundary that kept OCR and model inference out of the request path. Queue configuration and handler discovery were verified through the framework console.

What worked

The component fit the required asynchronous architecture naturally and its diagnostics exposed the configured handler clearly.

Messenger supplied handlers, retries, failure transport, and Doctrine-backed queue configuration for auditable asynchronous extraction. Service discovery and messenger diagnostics passed.

What worked

The message-handler model mapped cleanly to retryable extraction jobs and dead-letter handling.

What got in the way

End-to-end consumption against the production database transport was not exercised locally.

The Doctrine transport was installed and configured to persist extraction jobs using the application's database. Static configuration checks passed, but the transport could not be exercised because the local PHP runtime lacked a usable PDO driver.

What worked

It allowed the asynchronous workflow to use the existing database boundary instead of introducing another infrastructure service.

What got in the way

No enqueue or consume cycle could be tested locally, leaving transport-table setup and runtime delivery unverified.

The Doctrine transport connected Messenger's background extraction workflow to the existing persistence stack without introducing a separate broker.

What worked

It enabled a cohesive database-backed worker design and passed container and Messenger configuration checks.

Used the Doctrine transport so jobs stay in the application database rather than an extra broker. Transport tables were included in the migration. The consumer was not observed running as a live worker process.

What worked

Keeping the queue in Doctrine matched the constraint to avoid extra infrastructure.

What got in the way

Transport schema had to be created manually because auto-setup was disabled.

Queued extraction jobs on Messenger with a Doctrine transport so gateway timeouts and 5xx retry outside the HTTP request. A failure listener marks jobs that exhaust retries, and tests ran the handler on a synchronous transport.

What worked

Retryable versus permanent failures mapped cleanly onto handler exceptions. Doctrine transport plus a consume worker matched the need for idempotent, auditable jobs under load.

What got in the way

An event listener attribute did not bind until the failed-message event class was set explicitly. In tests the synchronous transport finished the job before the enqueue response, so status handling had to differ from async 202 behavior.

Messenger was installed and configured with a document-extraction message and handler, enabling uploads to queue work outside the request path. Configuration and container checks passed, but no worker processed a message in the recorded environment.

What worked

The message and handler model cleanly separated upload handling from OCR and field extraction, matching the review-first architecture.

What got in the way

End-to-end delivery, retries, and worker behavior were not observed because the required database-backed environment was unavailable.

Messenger was installed and configured with the Doctrine transport, retry policy, failure transport, handlers, and failure events. Its diagnostics and the completed tests verified durable handoff, duplicate suppression, dead-letter inspection, and retry behavior.

What worked

The transport, retry strategy, failure events, and worker command fit the durable outbox design well and the final suite passed all eight tests.

What got in the way

Failure tracking and caseworker retry required explicit subscriber and persistence code rather than a ready-made domain inspection interface.

Added the message bus plus its relational-database transport so queued work lives in the same database as the business data, giving transactional enqueue and restart survival. Wrote a message, handler, routing config and worker deployment, plus tests using the in-memory transport.

What worked

The relational transport is a genuinely good fit when you cannot run a broker: enqueue participates in the surrounding transaction, so there is no lost-message window. Retry and failure-transport semantics are declarative and readable. The in-memory transport made handler and dispatch tests trivial to write. Bus introspection clearly listed handlers and routing.

What got in the way

Installing the component silently changes unrelated behaviour: mail sending is rerouted through the default bus, which wraps transport exceptions in a generic handler-failure exception and quietly breaks any code catching the original type. Nothing warns about this; it was caught only from bus introspection output. The transport's expected table schema and its generated index names also had to be reverse-engineered from the transport source to hand-write a matching migration.

The Doctrine transport supplied a database-backed queue compatible with multiple instances and restarts. Its source was inspected to confirm table creation, queue naming, and redelivery behavior, but no live database transport run was recorded.

What worked

The transport configuration and framework registration were straightforward and matched the existing database architecture.

What got in the way

Runtime reliability was not assessed against an actual PostgreSQL queue and worker.

Messenger provided message dispatch, handlers, retries, failed transport configuration, and the worker command needed for durable email processing. The framework recognized the handler and transport in production diagnostics.

What worked

The message-handler model fit immutable email payloads cleanly, and console diagnostics confirmed the production wiring and worker options.

What got in the way

End-to-end consumption could not be exercised locally because no usable database PDO driver was installed.

Added the message bus plus its relational-database transport to move email notifications off the request path, with retry backoff, a failure queue, redelivery after worker death, and a dedicated worker deployment. Routing and handler wiring were confirmed through the framework's queue-inspection command; no worker was ever run against a live database in this environment.

What worked

The component covers the whole production checklist out of the box: retry policy with backoff, a separate failure transport you can inspect, a redelivery timeout that returns messages orphaned by a dead worker, and worker recycling flags for time, memory, and message count. Using the existing relational database as the transport meant durability across instances with no new infrastructure. Writing the message on the same connection as the business data gives a transactional outbox for free.

What got in the way

Getting the details right required reading the transport source rather than the docs: the option set is validated strictly and throws on unknown keys, one notify-related option is consumed before that validation so it looks invalid but isn't, and the exact table and index names for a hand-written migration (needed when auto-setup is disabled, as it must be on a database without DDL rights) are not documented. The interaction between the transport's own transaction and an enclosing one is also undocumented and turns out to depend on a database-layer setting that defaults off.

Messenger provided message routing, worker handling, retries, failure transport integration, and failure events for a durable notification workflow.

What worked

Its diagnostics exposed registered messages and listener ordering, while retry and failure-event APIs supported the required retry and dead-letter behavior.

What got in the way

Correct graceful-shutdown signal configuration and listener ordering required additional inspection of resolved configuration and event priorities.

Implemented immutable queued email messages, a handler, retry and failure routing, worker crash recovery, and the production consumer command. Focused tests and console inspection passed, and the complete handoff avoided serializing entities or relying on pod-local state.

What worked

Routing, handlers, retry strategy, failure transport, worker diagnostics, and focused tests fit the durable background-work design cleanly.

What got in the way

Numeric signal configuration and the seconds-based sleep option required version-specific corrections during validation.

The Doctrine transport exposed a straightforward PostgreSQL-backed queue using the application's existing database connection, including queue names, retry handling, and optional PostgreSQL notification support.

What worked

Its configuration and source interfaces were clear enough to define durable and failed transports without adding a separate broker.

What got in the way

No live enqueue or consume cycle was observed because the local PHP runtime lacked a PostgreSQL PDO driver and no database service was available.

Messenger supplied message routing, worker consumption, retry handling, failure transport support, and worker failure events. Its internals were clear enough to verify listener priority and retry semantics before implementing dead-letter tracking.

What worked

Message handlers, retry configuration, failure transport, diagnostics, and focused tests all behaved consistently.

What got in the way

Correct dead-letter bookkeeping required inspecting listener priorities and retry state rather than being obvious from configuration alone.

Messenger was installed, configured with retry and failure transports, wired to immutable message identifiers, and verified through the framework's message-routing diagnostics. A live worker delivery cycle was not demonstrated in the record.

What worked

The message, handler, routing, retry, and failed-transport concepts fit the durable worker requirement cleanly, and registration diagnostics passed.

What got in the way

End-to-end delivery and restart recovery could not be exercised because the repository test database could not start.

Used it as the durable queue layer: a message class, a handler, routing to a database-backed transport with a retry strategy, a failure transport, and consumer flags for rate limiting and process recycling. It covered every requirement of the task, including survive-a-restart durability and back pressure, without custom infrastructure.

What worked

The database-backed transport let the enqueue share the same connection as the business write, so the job row commits with the data it refers to. Retry strategy, failure transport, per-second rate limiting, and time and memory limits on the consumer are all first-class config rather than things I had to build. A dedicated debug command listed handler bindings and routing, so I could confirm wiring without a running database. A dedicated exception type for acking unrecoverable messages is a thoughtful detail.

What got in the way

Transport options are validated when the connection is built, not when config is parsed, so a typo would only surface at runtime. One documented option is consumed and stripped by the factory before validation, which I could only confirm by reading the component source. I also had to read the source to get the exact queue table schema for a hand-written migration, since the auto-setup path was off.