Skip to content

merge queue: embarking main (5ba5553), #2036 and #2037 together#2050

Closed
mergify[bot] wants to merge 33 commits intomainfrom
mergify/merge-queue/1b68c71928
Closed

merge queue: embarking main (5ba5553), #2036 and #2037 together#2050
mergify[bot] wants to merge 33 commits intomainfrom
mergify/merge-queue/1b68c71928

Conversation

@mergify
Copy link
Copy Markdown

@mergify mergify bot commented Mar 5, 2026

✨ The merge conditions cannot be satisfied due to checks timeout. ✨

Branch main (5ba5553), #2036 and #2037 are embarked together for merge.

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

Required conditions of queue main for merge:

  • check-success = run-e2e-tests / fhevm-e2e-test
  • #approved-reviews-by >= 1 [🛡 GitHub branch protection]
  • #changes-requested-reviews-by = 0 [🛡 GitHub branch protection]
  • #review-threads-unresolved = 0 [🛡 GitHub branch protection]
  • branch-protection-review-decision = APPROVED [🛡 GitHub branch protection]
  • any of [🛡 GitHub branch protection]:
    • check-success = common-pull-request/lint (bpr)
    • check-neutral = common-pull-request/lint (bpr)
    • check-skipped = common-pull-request/lint (bpr)
  • any of [🛡 GitHub branch protection]:
    • check-skipped = coprocessor-cargo-listener-tests/cargo-tests (bpr)
    • check-neutral = coprocessor-cargo-listener-tests/cargo-tests (bpr)
    • check-success = coprocessor-cargo-listener-tests/cargo-tests (bpr)
  • any of [🛡 GitHub branch protection]:
    • check-success = coprocessor-cargo-test/cargo-tests (bpr)
    • check-neutral = coprocessor-cargo-test/cargo-tests (bpr)
    • check-skipped = coprocessor-cargo-test/cargo-tests (bpr)
  • any of [🛡 GitHub branch protection]:
    • check-success = coprocessor-dependency-analysis/dependencies-check (bpr)
    • check-neutral = coprocessor-dependency-analysis/dependencies-check (bpr)
    • check-skipped = coprocessor-dependency-analysis/dependencies-check (bpr)
  • any of [🛡 GitHub branch protection]:
    • check-success = gateway-contracts-deployment-tests/sc-deploy (bpr)
    • check-neutral = gateway-contracts-deployment-tests/sc-deploy (bpr)
    • check-skipped = gateway-contracts-deployment-tests/sc-deploy (bpr)
  • any of [🛡 GitHub branch protection]:
    • check-skipped = kms-connector-tests/test-connector (bpr)
    • check-neutral = kms-connector-tests/test-connector (bpr)
    • check-success = kms-connector-tests/test-connector (bpr)

Required conditions to stay in the queue:

---
checking_base_sha: 96a61c72f765a02f1f5380f3e0e76f6b38a2cb34
previous_failed_batches: []
pull_requests:
  - number: 2037
...

Eikix and others added 30 commits March 2, 2026 19:31
Add CI that deploys host-contracts from v0.11.0 via Docker, then
upgrades each contract (ACL, FHEVMExecutor, KMSVerifier, InputVerifier,
HCULimit) to the current branch using hardhat upgrade tasks.

Unlike the gateway-contracts equivalent, all upgrade steps are enabled.
…ializer

Only FHEVMExecutor (2→3) and HCULimit (2→3) actually bumped their
REINITIALIZER_VERSION between v0.11.0 and current. ACL (3→3),
KMSVerifier (2→2), and InputVerifier (3→3) are unchanged, so their
reinitializeV2 would revert with InvalidInitialization.
Same constant-condition exemption as gateway-contracts-upgrade-tests,
needed for the `if: false` on skipped upgrade steps.
…ERSION

Replace 5 hardcoded upgrade steps (with manual `if: false` guards) with
a single loop that compares REINITIALIZER_VERSION between the previous
release and current code. Only contracts whose version actually changed
are upgraded.

- Add upgrade-manifest.json as single source of truth for upgradeable contracts
- Extract PREVIOUS_RELEASE_TAG to env var (one place to bump per release)
- Remove actionlint exemption (no more constant `if: false` conditions)

Refs: zama-ai/fhevm-internal#379
…R_VERSION

Apply the same auto-detection pattern from host-contracts to gateway:
replace 7 hardcoded upgrade steps (all with `if: false`) with a single
loop that compares REINITIALIZER_VERSION between the previous release
and current code.

- Add upgrade-manifest.json listing all 7 upgradeable gateway contracts
- Extract PREVIOUS_RELEASE_TAG to env var (one place to bump per release)
- Remove last actionlint exemption for constant `if: false` conditions

Closes: zama-ai/fhevm-internal#379
A contract that's new (not in the previous release tag) has no previous
deployment to upgrade from. Without this guard, the loop would attempt
an upgrade because the missing file defaults to version 0, which differs
from the current version.

Verified against the v0.9.8 → v0.10.0 gateway cycle: ProtocolPayment
is correctly skipped (didn't exist in v0.9.8), matching the original
manual `if: false` behavior.
…iable

The directive only suppresses the next line, not a block.
- Remove ProtocolPayment from gateway upgrade manifest (no hardhat
  upgrade task exists for it yet)
- Add existence check for contracts/${name}.sol in current code to
  fail fast if manifest is out of sync
- Fix misleading CHAIN_ID_GATEWAY comment in host workflow
…new contracts

- Replace silent :-0 fallback with explicit error when
  REINITIALIZER_VERSION cannot be parsed from an existing .sol file
- Skip version verification for contracts with no deployment address
  (new contracts not present in previous release)
…acts

Only skip version verification for genuinely new contracts (not in
previous release). If a contract existed in the previous release but
has no address variable mapped, fail with a clear error instead of
silently skipping.
The upgrade loop runs each contract upgrade as a separate npx hardhat
process. The .openzeppelin manifest and Hardhat cache/artifacts persist
on disk between invocations, causing flaky failures where the OZ plugin
reuses stale bytecode-hash entries or Hardhat resolves wrong artifacts
when previous-contracts/ and contracts/ share the same contract name.

Add `npx hardhat clean` and `rm -rf .openzeppelin` before each upgrade
to ensure a clean slate for compilation and deployment deduplication.
…ccess

The OZ hardhat-upgrades plugin's upgradeProxy() does NOT call .wait() on
the upgradeToAndCall transaction — it returns as soon as the tx is
submitted to the node. With Anvil's interval mining (--block-time 0.5),
the tx may not be mined when the plugin returns, and if it reverts during
mining, the revert goes completely undetected.

This caused flaky CI failures where the upgrade task printed "Proxy
contract successfully upgraded!" but getVersion() still returned the old
version — the upgradeToAndCall tx had silently reverted.

Fix: explicitly .wait() on the upgrade transaction, check the receipt
status, and read the EIP-1967 implementation slot to confirm the upgrade
took effect on-chain.
…rade

The OZ hardhat-upgrades plugin does NOT call .wait() on the
upgradeToAndCall transaction — it returns as soon as the tx is submitted.
With Anvil's interval mining (--block-time 0.5), the tx may still be
pending when the plugin returns, and if it reverts during mining the
revert goes undetected.

After each upgrade task:
1. Force-mine a block via `cast rpc evm_mine` to flush pending txs
2. Immediately verify getVersion() returns the expected value
3. Fail fast with a clear diagnostic if the upgrade was silently dropped

This catches the silent revert at the point of failure rather than later
in the separate verify step, making the error message actionable.
…ation

The inline per-upgrade version check duplicated the existing "Verify
contract versions" step.  Keep only the `cast rpc evm_mine` workaround
(OZ upgradeProxy does not wait for the upgradeToAndCall tx to be mined)
and let the dedicated verification step handle on-chain assertions.
Eikix and others added 3 commits March 5, 2026 11:40
…grades

The per-iteration `npx hardhat clean` + `rm -rf .openzeppelin` was a
speculative fix from before the real root cause was identified (missing
evm_mine).  Each contract has unique bytecode (no OZ manifest hash
collision) and tasks already use fully qualified artifact names, so
there is nothing to clean between iterations.
@mergify
Copy link
Copy Markdown
Author

mergify bot commented Mar 5, 2026

🧪 CI Insights

Here's what we observed from your CI run for 15bdb80.

🟢 All jobs passed!

But CI Insights is watching 👀

@mergify mergify bot closed this Mar 6, 2026
@mergify mergify bot deleted the mergify/merge-queue/1b68c71928 branch March 6, 2026 02:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants