Skip to content

test: stop mercure tests hitting a public hub - #8489

Merged
soyuka merged 1 commit into
4.3from
fix/mercure-testhub-no-network
Sep 1, 2026
Merged

test: stop mercure tests hitting a public hub#8489
soyuka merged 1 commit into
4.3from
fix/mercure-testhub-no-network

Conversation

@soyuka

@soyuka soyuka commented Sep 1, 2026

Copy link
Copy Markdown
Member

What

Mercure tests in the general PHPUnit matrix published to the public https://demo.mercure.rocks. When that third party hiccups, jobs go red — it caused 2 of the reds on 4.3 today (PHPUnit (PHP 8.3), PHPUnit (PHP 8.5) (Symfony 8.1)), and a plain re-run went green with no code change.

Root cause

The fixture app declared two mercure hubs on the same URL:

mercure:
    hubs:
        default: { url: '%env(MERCURE_URL)%', ... }
        debug:   { url: '%env(MERCURE_URL)%', ... }

MercureBundle registers one messenger handler per hub, and both are tagged messenger.message_handler for the same Update message:

  • mercure.hub.default.message_handlermercure.hub.default.traceableTestHub
  • mercure.hub.debug.message_handler → real Hub

So every async mercure update was published twice — once through TestHub (recorded, and what the assertions read) and once straight over the network through an unguarded hub. TestHub was also a decorator rather than a fake: publish() recorded and forwarded, even though nothing anywhere consumes its return value.

The debug hub existed only to be TestHub's inner; nothing targets it by name.

Change

  • Collapse the second hub into a plain app.mercure.inner_hub service, so a single messenger handler remains and the duplicate publish is gone.
  • TestHub gains $publishToHub (default false): it always records, and forwards only when asked.
  • config_mercure.yml (APP_ENV=mercure) sets app.mercure.publish_to_hub: true, so the dedicated PHPUnit (Mercure) job keeps real end-to-end coverage against its local hub container.
  • MERCURE_URL now defaults to http://localhost:1337/.well-known/mercure — the hub that job already runs — instead of a public URL.
  • New TestHubTest locks the invariant in, so re-introducing forwarding fails loudly instead of going quietly flaky.

No changes to .github/workflows/ci.yml were needed.

Two assertions hardcoded demo.mercure.rocks and were updated. Note testNoDiscoveryLinkOnNonMercureEndpoint previously asserted the absence of a .../hub URL that was never emitted, so it was vacuous; it now asserts the absence of the real discovery link.

Verification

  • tests/Functional/Mercure/ + SubscriptionTest: 9 tests, 84 assertions, green fully offline (before this change they died at 22 assertions).
  • app.mercure.publish_to_hub resolves true under APP_ENV=mercure, false under test.
  • php-cs-fixer: 0 fixes. PHPStan: clean on the changed files (local run shows only the usual Doctrine\ODM\MongoDB class.notFound noise on untouched lines).

I stopped a local full-suite run partway for thermal reasons — CI is the authority on the full matrix here.

The fixture app declared two mercure hubs on the same URL. The bundle registers one
messenger handler per hub and both are tagged for the same Update message, so every
async update was published twice: once through TestHub, which the assertions read,
and once straight to demo.mercure.rocks through an unguarded hub. That third party
going down turned into red PHPUnit jobs on every branch.

Collapse the second hub into a plain inner service so a single handler remains, and
let TestHub record without forwarding unless the dedicated mercure env asks for it.
MERCURE_URL now defaults to the local hub that env's CI service already runs.
@soyuka
soyuka merged commit 6437c83 into 4.3 Sep 1, 2026
112 of 113 checks passed
@soyuka
soyuka deleted the fix/mercure-testhub-no-network branch September 1, 2026 13:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant