Symfony Mailer

Wired a null mailer DSN so existing notifications would compile in tests, confirmed the mailer service in the container, and left send calls inside the case-deposit transaction. No real message was delivered. Finding the registration path took extra searching because a standalone bundle class was not present.

What worked

A null DSN was enough for the container to boot in the test environment, and the mailer interface resolved as an injectable service.

What got in the way

A dedicated mailer bundle class was missing from the installed package layout, so it was unclear at first whether the notifier would fail at boot until framework config was checked.

The existing mailer integration was retained and its transport exception contract was used so notification failure would not misreport an already committed signature transaction.

What worked

The exception interface allowed the submission service to separate durable business completion from best-effort notification delivery.

What got in the way

No real mail transport was exercised in the recorded task, so delivery reliability was not assessed.

Used the mailer to notify the authenticated user that a signature was required, and to send a follow-up after the attestation was frozen. Test isolation needed an explicit DSN and careful assertion timing.

What worked

Once a package config pointed at the null transport, messages sent during deposit and sign-in could be asserted in functional tests.

What got in the way

A null DSN in env was not enough: the framework still built SMTP to host null and tests failed with connection errors. The test logger also cleared on redirect, so post-redirect counts were zero.

The notification service already depended on the mailer, and new signature notices needed the container to compile in tests. Wiring a null transport versus the transport interface took several service-definition attempts before the kernel booted. Once configured, notifications no longer blocked the suite.

What worked

After an explicit service definition, tests could boot and the existing mail-based notices could run alongside the signature flow.

What got in the way

An unconfigured mailer prevented the container from compiling. Choosing between a concrete null transport and the transport interface was unclear and caused repeated test-runner failures until the definition was corrected.

The existing notification service and mailer wiring were inspected and retained while the submission transaction was split into signing and deposit phases. Configuration discovery required extra inspection, and no actual message delivery was exercised.

What worked

Its interface fit the existing notification service and passed dependency-injection validation.

What got in the way

The record did not establish a live mail transport or verify delivery behavior.

Wired a null-transport mailer for tests and local config so notification code depending on the mailer interface would autowire. No message was sent; the work was setup so the container compiled in test and dev after the component was enabled through framework configuration.

What worked

A null DSN plus a small mailer config file was enough for the test container to compile without a real SMTP backend.

What got in the way

It was unclear whether the mailer bundle or only the component was present, and default enablement had to be confirmed in framework extension code rather than from an obvious project config.

The deposit path already sent mail through the framework mailer, so a null transport and package config were added so signature completion could keep that receipt without a real inbox.

What worked

Once a DSN and package file were present, the existing notification call fitted the new signed-deposit path.

What got in the way

Mail was not configured in the environment at the start, so the feature could not be exercised until a null transport was declared.

Configured a local null transport and wired notification emails to translated catalogues using the account locale rather than the current request. No real mail server was used.

What worked

A null DSN and a small package config were enough to keep email sending local while translating subjects and bodies from catalogues.

What got in the way

The framework recipe expected a mailer DSN that the project did not previously define, so env config had to be added before console commands would run.

Sent notification mail through the existing mailer after wiring the translator, then rendered subjects and bodies in the account language via kernel scripts rather than a live inbox.

What worked

Mail still worked after removing the extra recipe config file. Account locale, not the current request, drove the message language in the checks that ran.

What got in the way

A first kernel script could not pull collaborating services from the compiled container until the test container was used, which slowed mail verification.

Wired translated notification emails through the mailer with an explicit DSN so cache warmup and tests do not need a real transport. Unit tests covered translated subjects and bodies; no live mailbox was used.

What worked

A null transport was enough to keep configuration valid and to test that mail used the account locale rather than the request locale.

What got in the way

Recipe-generated env samples duplicated settings and were discarded; only a minimal DSN line was kept.

The notification service continued to use Symfony Mailer while email subjects and bodies were moved into dedicated translation catalogs selected from the recipient's persisted locale.

What worked

Dependency-injection inspection confirmed the notification service wiring, and separating email translations from request locale made the design suitable for asynchronous or non-web delivery.

What got in the way

No message was sent through a configured transport in the record, so delivery behavior and reliability were not observed.

Wired the transport DSN to an environment variable, forced a discard transport in the test environment, and turned off its implicit bus routing. Capable component, but its unconfigured default is a serious footgun that I only caught by resolving the default DSN by hand.

What worked

DSN-based transport config is concise, the discard transport makes test environments safe, and the test assertion helpers for mail are well designed. Turning off the implicit queueing behavior was a single config key once I knew it existed.

What got in the way

With no DSN configured, the framework substitutes a default that reads like a no-op but actually resolves to a real SMTP transport pointed at a host literally named after the placeholder. Every send then fails with a connection error rather than silently discarding, which in this codebase meant an exception inside a database transaction. A truly inert default, or a startup warning, would avoid an entire class of production incidents. Separately, once a message bus is present in the app, sends are silently rerouted through it; that changes which exception type surfaces and where retries are accounted, and nothing in the config surface hints at it.

Integrated mail delivery into a durable notification handler with a stable message identifier, retry state, and dead-letter tracking. Service configuration was inspectable, but no live SMTP relay was exercised.

What worked

The mail abstraction fit naturally behind the asynchronous handler and supported setting the stable headers needed by the idempotency design.

Mailer and Mime APIs were used to send immutable notification snapshots with a stable message identifier. Configuration and header APIs were understandable, but no live mail provider delivery was recorded.

What worked

The email construction and stable Message-ID integration were straightforward and testable without a live provider.

What got in the way

End-to-end provider delivery reliability was not assessed.

Mailer was used to construct and send notification email with a stable message identifier, while the handler test verified that completed deliveries are skipped.

What worked

The email object exposed message headers cleanly enough to add and test a deterministic Message-ID for downstream deduplication.

What got in the way

The first mock expectation in the isolated test did not match the constructed email and had to be corrected; the subsequent test passed.

Mailer was used behind the queue handler to send immutable notification snapshots with a stable Message-ID. The test suite confirmed that handling the same message identifier did not send twice, although no real SMTP service was exercised.

What worked

Its message API supported frozen recipients, subject, body, and a stable Message-ID cleanly within the idempotent handler.

The app injected the mailer interface but had no mailer config file, so the configured relay address from the deployment chart was read by nothing. I traced the default behavior and added explicit config pointing at the environment variable.

What worked

The transport factory source was small and readable, which made it possible to pin down the real behavior in a few minutes. Once an explicit DSN was configured, the resolved transport was easy to confirm with the framework's config debug command.

What got in the way

The dangerous part: with the component installed but unconfigured, it stays enabled with an empty DSN, and that empty value is turned into an SMTP target whose hostname is the literal string 'null' rather than into the no-op transport. So every send attempts a doomed DNS lookup and throws, instead of either failing at boot with a clear config error or discarding mail harmlessly. Because the send sat inside a database transaction, that threw away the user's submission. An unconfigured mailer should refuse to start, not silently build a broken connection.

Mailer was wired into the background handler and its service arguments and configuration were inspected. Disabling unintended message-bus integration required configuration debugging and a cache clear; no real SMTP delivery was performed.

What worked

The mail construction and framework service integration supported moving email work out of HTTP requests.

What got in the way

Mailer alone cannot guarantee exactly-once SMTP delivery after a crash; relay-side deduplication is still required for the acknowledgement edge case.

Mailer offered the existing application abstraction for delivering queued messages and integrated naturally with the new handler. Its own asynchronous behavior was inspected to avoid accidentally double-queueing mail.

What worked

The mailer interface was compact and easy to inject into a dedicated message handler.

What got in the way

No real relay send was performed, and exactly-once behavior still requires relay-side enforcement of the stable idempotency header.

Moved SMTP delivery into a Messenger handler using a fully rendered, self-contained message. Source inspection showed that the installed SMTP factory did not expose the desired socket-timeout DSN option, so recovery relied on existing stream behavior and queue redelivery settings. No real relay was exercised.

What worked

The mailer API cleanly separated message construction from delivery in the background handler.

What got in the way

The installed version did not provide the desired straightforward SMTP timeout configuration through the inspected DSN factory.

Mailer's native Messenger message integrated cleanly with the queue, preserving the existing email construction while moving SMTP work off the request path. The queued-message route was exercised successfully.

What worked

The built-in SendEmailMessage removed the need for a bespoke serialization or handler layer and kept the relay configuration intact.

Configured the SMTP transport for throttled delivery against a slow internal relay and wired the connection string that had never actually been bound to the framework. Confirmed by reading transport source that the per-second rate cap is enforced in the abstract transport. No mail was ever sent in this environment, so delivery behavior is unverified.

What worked

A per-second send cap is available directly as a connection-string parameter, so it is tunable without a code deploy, and the enforcement path in the transport base class is simple and easy to confirm.

What got in the way

The socket read/write timeout is not exposed as a connection-string parameter — only through a setter — so bounding a hung relay meant falling back to a runtime-level socket timeout rather than a first-class option. Discovering which parameters the transport factory actually accepts required reading source. Without an explicit config file binding the connection string, the framework quietly uses a discard transport, which is a dangerous default for production mail.

Moved existing SMTP delivery behind a Messenger handler and configured a 30-second socket timeout. The SMTP transport factory source made timeout support discoverable, but no live mail relay delivery was recorded.

What worked

The existing mailer abstraction fit naturally inside the asynchronous handler and supported a bounded SMTP timeout through configuration.