In the _executeProposal function, the contract checks whether the timelock operation is ready for execution by calling _timelock.isOperationReady(id). If this check fails, the function reverts with the error ProposalNotQueued(proposalId, id). However, this error message is misleading: it implies that the proposal was never queued, when in fact the proposal might be queued but not yet ready (i.e. the timelock delay has not passed).
The error message ProposalNotQueued is used regardless of whether the proposal is queued but not ready or not queued at all. This can cause confusion for developers and users when debugging or interacting with the system.
Correct Approach:
Ideally, the function should differentiate the two cases:
If the proposal is queued but not yet ready, revert with a more accurate error (e.g., ProposalNotReady).
If the proposal is not queued at all, then revert with ProposalNotQueued.
Governance.sol :
Ensure that all parts of the proposal lifecycle accurately reflect the state of the operation in the timelock.
Improve Error Messaging:
Modify the _executeProposal function to differentiate between the two conditions:
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.