B4 — declare the journal tables to Doctrine, which wanted to drop them

[gplanchat]

Second audit finding. doctrine:migrations:diff was generating DROP TABLE statements against the journal.

The defect

The four tables of the DBAL bridge were declared to Doctrine by no configureSchema and no postGenerateSchema listener. addToSchema() was only ever called by ensure(), that is, by the bridge itself — verified, a single caller in the whole repository.

A docblock claimed otherwise:

Declares the missing tables; also wired to configureSchema on the bundle side.

Consequence: Doctrine's tooling builds the expected schema from entities alone, does not find these tables, and treats them as orphans. The generated migration drops them — the journal, and with it every in-flight execution.

The fix

DurableSchema::configureSchema(Schema $schema, Connection $forConnection, \Closure $isSameDatabase) takes the signature of the three upstream adapters that solve exactly this problem — DoctrineDbalAdapter, DoctrineTransport, DoctrineDbalStore — database probe included. It skips, table by table, the ones the schema already carries.

A listener in the bundle wires it to postGenerateSchema, registered only if the ORM's event class exists: the DBAL bridge works without the ORM, and an application that only has DBAL has no schema to complete.

auto_setup

It accompanies the fix rather than widening it: once migrations own the schema, the bridge's lazy creation writes behind their back. Defaults to true, so nothing changes unless asked. This is the switch the Doctrine transport exposes for the same reason.

Tests

Six cases, RED first (Call to undefined method ...::configureSchema(), Unknown named parameter $autoSetup):

• the four tables join an empty schema;
• a table already present is not redeclared, the others still are;
• nothing is declared when the probe says "different database";
• everything is declared when it says "same database" on another connection;
• auto_setup: false creates no table;
• auto_setup at its default still creates all four — regression net, this case already passed.

Documentation

The bridge README carried "there is no migration to run" without saying what happened if the application did have one. It now carries the declaration, the connection boundary and auto_setup. The docblock that lied is corrected.

---

Addendum — 2026-09-04, after cross-review

The original text justified a deliberate caution: the listener did not lean on the upstream AbstractSchemaListener, because filterSchemaChanges() "is recent and does not exist across the whole ^6.4 || ^7.0 || ^8.0 range". It therefore declared the tables only when the journal writes on the very Connection object the ORM inspects, passing static fn(): bool => false as the probe.

The premise was wrong, and seven independent review axes reached it. AbstractSchemaListener::getIsSameDatabaseChecker() is declared identically on v6.4.0, 7.2 and 8.0 — checked against the source. What moved is filterSchemaChanges(), the other method. With the justification gone, so was the caution it funded: as soon as the journal has its own named connection — the case this branch's own README describes — nothing was declared and doctrine:migrations:diff went back to generating its DROP TABLE. B4 was closed for the default case and silently reopened for the case it targeted.

The probe is now copied from AbstractSchemaListener — twenty lines that depend only on DBAL — rather than inherited: it is protected there, and extending the class would impose symfony/doctrine-bridge on the bundle.

Two more things the review found, both now fixed:

• doctrine/orm had been written into require-dev by hand, out of alphabetical order despite sort-packages, and never resolved. The eight jobs that run composer install were red: no test had ever run on this branch. The ^2.19 half of the constraint was unsatisfiable here anyway — ORM 2 wants DBAL ^2.13.1 || ^3.2, the bridge wants ^3.7 || ^4.0, and the lock carries DBAL 4.4.4. Constraint narrowed to ^3.0, lock updated.
• The only production path had no test. The six cases above call configureSchema() and pass it the probe, which proves the shape of the schema and never the decision to declare. DurableSchemaListenerTest now exercises postGenerateSchema() with the real probe on three cases; the second one fails on the code that preceded this addendum.

Still open, out of scope for this branch: the schema_filter bypass (upstream goes through filterSchemaChanges(), absent in 6.4), and the lack of a supported creation path when auto_setup: false — a durable:setup, along the lines of messenger:setup-transports.