While reviewing the authority mocks, I noticed a small mismatch in the delayed authority mock.
AuthorityDelayMockUpgradeable.canCall returns (bool, uint256), but the delay value is typically treated as a uint32 in access manager–style interfaces. This can make the mock slightly inconsistent with how delay values are consumed in practice.
Additionally, AuthorityNoResponseUpgradeable.canCall intentionally returns no data, but this isn’t immediately obvious when reading the code and could be confusing without context.
Suggested changes:
- Align the delayed
canCall return type to uint32
- Add a short comment clarifying that the no-response authority is intentional and used for robustness testing
Happy to open a PR if this direction makes sense.
While reviewing the authority mocks, I noticed a small mismatch in the delayed authority mock.
AuthorityDelayMockUpgradeable.canCallreturns(bool, uint256), but the delay value is typically treated as auint32in access manager–style interfaces. This can make the mock slightly inconsistent with how delay values are consumed in practice.Additionally,
AuthorityNoResponseUpgradeable.canCallintentionally returns no data, but this isn’t immediately obvious when reading the code and could be confusing without context.Suggested changes:
canCallreturn type touint32Happy to open a PR if this direction makes sense.