The Mercure job follows dunglas/mercure:latest and breaks on every pull request

Open Beginner friendly
#8,549 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
76/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
docker, github-actions, php
Domain
ci-cd

Research direction

Start in .github/workflows/ci.yml, where the PHPUnit (PHP 8.5) (Mercure) job declares the dunglas/mercure service image. Review the failing ApiPlatform\Tests\Test\ApiTestCaseTest::testGetMercureMessages test and the recorded image digests, then confirm the Mercure tag with a maintainer. Done means pull requests no longer follow an unpinned latest image and the Mercure test passes.

Written by the indexing model from the issue text.

Description

The PHPUnit (PHP 8.5) (Mercure) job fails on every pull request since some point between 2026-09-16 and today, on the same test:

1) ApiPlatform\Tests\Test\ApiTestCaseTest::testGetMercureMessages
{"detail":"Failed to send an update.","status":500}
It comes from the hub image, not from the pull requests

.github/workflows/ci.yml declares the service as image: dunglas/mercure, so the tag is latest and the runner pulls whatever is current:

image digest result
main, 2026-09-16 sha256:916834e4… green
#8479, today sha256:33223c37… fails
#8548, today, not mine sha256:33223c37… fails, same test

Both of today's runs log Status: Downloaded newer image for dunglas/mercure:latest. A pull request that touches nothing related to Mercure fails exactly like one that does, which points at the image rather than at the changes.

I have not worked out what the new image changed, only that the job follows the digest. MERCURE_EXTRA_DIRECTIVES and the JWT keys in the workflow are the kind of configuration a hub release can tighten.

Suggestion

Pinning the service to a released tag, dunglas/mercure:v0.19 or whichever line you track, would keep a hub release from turning every pull request red, and would make the upgrade a deliberate commit you can review on its own.

Happy to send that pull request if you tell me which tag you want to sit on. I would rather not pick the version for you.

Dominant language
PHP
Stars
2.6k
Forks
982
Avg merge
1d 18h
Merged PRs (30d)
45

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from api-platform/core

All issues in api-platform/core

Similar issues

More PHP issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.