E2E: remove AccessManager role-id checks for canceler/operator; align docs on role 1 vs 2

PlasticDigits commented

2026-04-06 05:04:42 +00:00

(Migrated from gitlab.com)

Summary

E2E currently grants and/or asserts AccessManager roles using IDs named like operator/canceler (e.g. role 1 / 2). **Bridge does not use AccessManager for withdrawApprove / withdrawCancel**—authorisation is addOperator / addCanceler (and owner where applicable). Those grantRole / hasRole checks are misleading and can diverge from production RBAC.

Tasks

E2E
- Remove or replace tests that validate canceler/operator behaviour via AccessManager role IDs (1, 2, or constants named OPERATOR_ROLE_ID / CANCELER_ROLE_ID).
- Prefer setup/assertions against Bridge: e.g. addOperator / addCanceler, or deployment owner / initialize operator, matching how the contract actually gates calls.
- Drop dead grantRole calls if nothing meaningful consumes them after the refactor.
Docs
- Document AccessManager role 1 and role 2 by their real purposes (per deployment/runbooks): e.g. MintBurn/minter flows vs guard-stack admin (TokenRateLimit / GuardBridge as applicable).
- Explicitly state that these are not Bridge operator/canceler; Bridge uses addOperator / addCanceler.

Context

packages/e2e: chain_config.rs, setup/evm.rs, and any fraud/detection tests that hasRole on AccessManager for canceler/operator semantics.
Main docs: README.md, docs/deployment-guide.md, docs/deployment-solana-mainnet.md / OPERATIONAL_NOTES as needed so role 1/2 are not confused with Bridge RBAC.

Acceptance criteria

No E2E path relies on mislabeled AccessManager roles to stand in for Bridge canceler/operator.
Docs clearly separate AccessManager role 1 & 2 from Bridge operator/canceler.

## Summary E2E currently grants and/or asserts `AccessManager` roles using IDs named like operator/canceler (e.g. role `1` / `2`). **`Bridge` does not use `AccessManager` for `withdrawApprove` / `withdrawCancel`****—authorisation is **`addOperator` / `addCanceler`**** (and owner where applicable). Those `grantRole` / `hasRole` checks are misleading and can diverge from production RBAC. ## Tasks 1. **E2E** - Remove or replace tests that validate canceler/operator behaviour via **`AccessManager` role IDs** (`1`, `2`, or constants named `OPERATOR_ROLE_ID` / `CANCELER_ROLE_ID`). - Prefer setup/assertions against **`Bridge`**: e.g. `addOperator` / `addCanceler`, or deployment owner / `initialize` operator, matching how the contract actually gates calls. - Drop dead `grantRole` calls if nothing meaningful consumes them after the refactor. 2. **Docs** - Document **AccessManager role 1** and **role 2** **by their real purposes** (per deployment/runbooks): e.g. MintBurn/minter flows vs guard-stack admin (`TokenRateLimit` / `GuardBridge` as applicable). - Explicitly state that these **are not** Bridge operator/canceler; Bridge uses **`addOperator` / `addCanceler`**. ## Context - `packages/e2e`: `chain_config.rs`, `setup/evm.rs`, and any fraud/detection tests that `hasRole` on `AccessManager` for canceler/operator semantics. - Main docs: `README.md`, `docs/deployment-guide.md`, `docs/deployment-solana-mainnet.md` / `OPERATIONAL_NOTES` as needed so role 1/2 are not confused with Bridge RBAC. ## Acceptance criteria - [ ] No E2E path relies on **mislabeled** AccessManager roles to stand in for Bridge canceler/operator. - [ ] Docs clearly separate **AccessManager role 1 & 2** from **Bridge operator/canceler**.

PlasticDigits commented

2026-04-20 03:27:34 +00:00

(Migrated from gitlab.com)

mentioned in commit f1d175e34a

mentioned in commit f1d175e34a7d6dfe0e600c1d58e62a7c150fcb5b

PlasticDigits commented

2026-04-20 03:27:39 +00:00

(Migrated from gitlab.com)

Resolved in `main` (`f1d175e`)

E2E

Stopped using AccessManager.grantRole with numeric IDs 1 and 2 as a stand-in for Bridge operator/canceler.
Added ensure_bridge_rbac_for_e2e / grant_test_account_roles paths that use Bridge.addOperator / addCanceler and cast call on isOperator / isCanceler, matching production withdraw RBAC.
Updated tests (fraud, configuration, canceler, watchtower): assert Bridge cancel/operator capability via query_bridge_is_canceler / query_bridge_is_operator; renamed AccessManager helper to query_access_manager_has_role and documented role 1 as minter/MintBurn-stack smoke only.
Removed dead deploy.rs AccessManager grant helpers and OPERATOR_ROLE_ID / CANCELER_ROLE_ID exports.

Docs & CI

deployment-guide.md and deployment-solana-mainnet.md: spell out AM role 1 vs 2 (MintBurn/minter vs guard stack) vs Bridge addOperator / addCanceler.
.github/workflows/e2e.yml: pre-test step now calls Bridge.addCanceler instead of AM grantRole.

Misc

Canceler service user-facing log lines no longer refer to a nonexistent CANCELER_ROLE on AccessManager for Bridge.

Closing as addressed.

## Resolved in `main` (f1d175e) ### E2E - **Stopped** using `AccessManager.grantRole` with numeric IDs **1** and **2** as a stand-in for Bridge operator/canceler. - **Added** `ensure_bridge_rbac_for_e2e` / `grant_test_account_roles` paths that use **`Bridge.addOperator` / `addCanceler`** and **`cast call` on `isOperator` / `isCanceler`**, matching production withdraw RBAC. - **Updated tests** (fraud, configuration, canceler, watchtower): assert Bridge cancel/operator capability via `query_bridge_is_canceler` / `query_bridge_is_operator`; renamed AccessManager helper to `query_access_manager_has_role` and documented role **1** as minter/MintBurn-stack smoke only. - **Removed** dead `deploy.rs` AccessManager grant helpers and **`OPERATOR_ROLE_ID` / `CANCELER_ROLE_ID`** exports. ### Docs & CI - **deployment-guide.md** and **deployment-solana-mainnet.md**: spell out **AM role 1 vs 2** (MintBurn/minter vs guard stack) vs **Bridge `addOperator` / `addCanceler`**. - **\.github/workflows/e2e.yml**: pre-test step now calls **`Bridge.addCanceler`** instead of AM `grantRole`. ### Misc - **Canceler** service user-facing log lines no longer refer to a nonexistent `CANCELER_ROLE` on AccessManager for Bridge. Closing as addressed.

PlasticDigits (Migrated from gitlab.com) closed this issue

2026-04-20 03:27:42 +00:00

Brouie commented

2026-04-21 05:20:06 +00:00

(Migrated from gitlab.com)

mentioned in issue #111