Skip to content

merge queue: checking #1801 on main (249fbd4) - #1813

Closed
mergify[bot] wants to merge 3 commits into
mainfrom
mergify/merge-queue/d9df04c428
Closed

merge queue: checking #1801 on main (249fbd4)#1813
mergify[bot] wants to merge 3 commits into
mainfrom
mergify/merge-queue/d9df04c428

Conversation

@mergify

@mergify mergify Bot commented Sep 7, 2026

Copy link
Copy Markdown
Contributor

🎉 This pull request has been checked successfully and will be merged soon. 🎉

#1801 is queued for merge on branch main (249fbd4).

This pull request has been created by Mergify to check the mergeability of #1801.
You don't need to do anything. Mergify will close this pull request automatically when it is complete.

Required conditions of queue rule default for merge:

Required conditions to stay in the queue:

---
checking_base_sha: 249fbd47a610ec787ff9566d973815624f704461
previous_check_retries: []
previous_failed_batches: []
pull_requests:
  - number: 1801
    scopes: []
scopes: []
...

jd and others added 3 commits September 7, 2026 14:08
The module header promised this file "deliberately mirrors the
Python version 1:1 ... so the port can't drift the contract by
accident", and named `func-tests/test_live_smoke.py` and
`func-tests/conftest.py` as what it mirrors. Both were deleted when
the port completed. Four helpers made the same promise individually
(`Mirrors conftest.py::cli`, `Mirrors Python subprocess.run`,
`Matches Python result.stdout + result.stderr`, and `live_token`'s
"Mirrors Python `live_token` fixture").

AGENTS.md: "There is no Python: the port is complete ... If you
find a doc, comment, or rule mentioning [it], it is stale — fix
it." The harm is concrete rather than cosmetic: a maintainer
auditing which secret each test needs goes looking for the fixture
the header says pins that mapping, and there isn't one.

The header now states the invariant that actually holds — tests are
grouped by credential under a banner, and a test belongs under the
banner matching its helper — which is the thing a reader needs and
the thing the previous commit had to correct. It also spells
`LIVE_TEST_MERGIFY_TOKEN_ADMIN` out rather than abbreviating it to
`_ADMIN`, so grepping for either secret finds this file.

Left alone: the in-body notes recording which wire contracts were
preserved across the Python → Rust port. Those are provenance for
why a contract is shaped the way it is, not claims about a file
that no longer exists.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JBz3hxMUDCuWftT6qAHtnn

Change-Id: Idd9e1e28bfc50b8b71d07c5938b4fa89af2745ff
MRGFY-9001 dropped `ci_application_key` from `POST` and `DELETE` on
`/ci/{owner}/repositories/{repo}/quarantines` at the same time it
dropped it from `search/tests`. Only `search/tests` had a live
test, so only `search/tests` turned red; `mergify tests quarantines
add` and `remove` broke for every `ci` key with no signal at all.
The first two commits of this stack documented that. This closes
it.

The 20-odd wiremock tests in `tests_quarantine.rs` cannot cover
this: a mock server never authenticates, so no scope change is
visible to them. It has to be the live suite or nothing.

Shape follows `freeze_create_update_delete_roundtrip`, the existing
create-and-clean-up test in this file: a `Drop` guard removes the
entry so a failed assertion mid-test still leaves the canary
repository clean, and it warns rather than panics, because
panicking in `Drop` during an unwind aborts the process and buries
the assertion message that explains the failure. The guard is
registered before the response is parsed — an unparseable body
still means the row exists server-side.

Two details specific to quarantines:

- The quarantined name is `__mergify_cli_smoke_quarantine_<rand>__`
  and matches nothing any real suite reports, so even a completely
  skipped cleanup cannot suppress a genuine failure on the canary
  repository. A leaked row is inert.
- Removal goes by name rather than by the id `add` returned, so one
  run covers the list read that resolves the name *and* the delete.

The guard tolerates exactly two outcomes: exit 0, when the body
failed before its own remove, and `MergifyApiError` carrying
`not_found`'s `'<name>' is not quarantined`, when the body already
removed the row. Both halves are load-bearing — that exit code is
every Mergify API error including a 403 on a narrowed scope, and
the message on its own would swallow any failure whose text
happened to contain the phrase. It reads the code off
`mergify_core::ExitCode` rather than a literal, so a renumbering
cannot silently widen what cleanup calls success.

The 8-char entropy the freeze test generated inline is now
`unique_suffix()`, shared by both.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Change-Id: I20ed0098fe86acd633ad6864eed035f6e5f47dd1
@mergify
mergify Bot deployed to Mergify Merge Protections September 7, 2026 13:48 Active
@mergify
mergify Bot deployed to func-tests-live September 7, 2026 13:48 Active
@mergify mergify Bot closed this Sep 7, 2026
@mergify
mergify Bot deleted the mergify/merge-queue/d9df04c428 branch September 7, 2026 13:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant