DEVEX: detect silent common freeze + fail loudly + alert Slack

[pdodgen-revparts]

Background

Fleet-wide 10-day silent regression 2026-07-31 → 2026-08-10:

Common v12.247 pinned `revolutionparts/ebay-fulfillment-api-php-client` to exact `1.0.3`. Apps whose composer.lock had `1.0.1` for that peer had `composer update revolutionparts/common` return "Nothing to modify in lock file" and exit 0, because composer's resolver correctly determined that upgrading common alone was unsatisfiable within the update whitelist. Nightly Common Update reported green every night while composer.lock stayed at v12.246.2 for 10 days on 7 repos.

The user-facing failure mode was invisible: no red X, no email, no Slack post. Only surfaced when a human happened to notice their app was on an old common.

Fix

Add a `Detect silent freeze` step between `Update Common` and `Commit Common Bump`. When composer update produces no lock change, compare the lock's common version against Packagist's latest via `composer show revolutionparts/common --latest --format=json`:

State	Action
lock changed	normal update path — commit + push
lock unchanged AND at latest	legitimate no-op → exit 0
lock unchanged AND lock < latest	SILENT FREEZE — dump `composer why-not` to job summary, exit 1, fire Slack (if configured)

Add optional `slack_webhook_url` secret. When set, failures also post to Slack. When not set, only the GH workflow failure signal fires (email, mobile, PR check).

Design vs the closed alternative

Considered making `composer update` more aggressive with `--with-all-dependencies` in #160 (now closed). Rejected because it papers over the real issue: upstream constraint choices that break the fleet should surface as failures we can respond to, not be silently worked around. The right forcing function is the workflow failure + Slack alert.

Coverage

Applies to every caller of `php-common-bump.yaml@main` — every RT participant's Nightly Common Update + Upgrade Common workflows pick it up automatically the next time they run.

Callers that pass `slack_webhook_url`

None currently. For those to get the Slack alert, each caller needs to add `slack_webhook_url: ${{ secrets.SLACK_WEBHOOK_URL }}` under `secrets:` in their Upgrade Common / Nightly Common Update workflow. That's a small opt-in sweep — happy to draft it as a follow-up PR set, but not required for this change to be useful (workflow failures still surface without Slack).

Companion PRs

• encodium/common — unpin `ebay-fulfillment-api-php-client` from exact `1.0.3` back to `^1.0.3` (root-cause fix for the specific freeze that motivated this PR)
• 7 per-repo unstick PRs (radmin / catalog_api / listings-url-service / payments / returns-api / rp_api / webstore) — manually push each stuck lock forward to peer 1.0.3 + common v12.255.3

Test plan

• Merge
• Confirm next Nightly Common Update on a repo already at latest common: freeze-check step logs "at latest", commit step logs "No changes to commit", workflow green (same as before)
• Confirm next Nightly Common Update on a repo with a lock update available: normal commit + push path (same as before)
• Once the seven unstick PRs merge, verify no stuck repos remain. Then, if a future common constraint change re-freezes any repo, expect the alert (red X + Slack)

[cursor]

PR Summary

Medium Risk
Changes fleet-wide reusable CI behavior: legitimate “already at latest” paths stay green, but repos stuck behind Packagist will start failing nightly bumps until locks are fixed—intentional but operationally noisy until callers opt into Slack.

Overview
Extends the reusable php-common-bump workflow so nightly/common-bump runs can’t report success when composer update revolutionparts/common leaves composer.lock unchanged but Packagist has a newer revolutionparts/common.

After Update Common, a new Detect silent freeze step skips when the lock changed; otherwise it compares the locked common version to composer show … --latest (JSON parsed via printf + jq). If lock < latest, it writes composer why-not and recovery steps to the job summary, sets frozen=true, and fails the job. An optional slack_webhook_url secret triggers a Post freeze alert to Slack step on that failure (incoming webhook mode, mirroring existing deploy notifications).

Callers without the webhook still get a red workflow; Slack is opt-in per caller.

^{Reviewed by Cursor Bugbot for commit 86d58e1. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit fbf3b9d. Configure here.}