Add state getter in TimelockController using OperationState enum

[RenanSouza2]

Fixes #4316
Fixes LIB-899

TimelockController

• remove:

• isOperationPending

• isOperationReady

• isOperationDone

• implement:

  • getOperationState

PR Checklist

• Tests
• Documentation
• Changeset entry (run npx changeset add)

[changeset-bot]

🦋 Changeset detected

Latest commit: 8d43f44

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
openzeppelin-solidity	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[frangio]

To reiterate, what is missing in this PR is to add back isOperationReady, etc., and I would add: to implement those functions in terms of getOperationState() so that getOperationState is the "source of truth".

[RenanSouza2]

And what is de decision for the pending name?

I suggest keep the pending meaning of 'operation scheduled but not done or canceled' because of the previous method 'isOperationPending'. And to create another name fot the state between scheduled but before the time alloed to execute like 'blocked'

[frangio]

Pending should preserve the meaning implied by isOperationPending in 4.x code.

I suggest the name pending be replaced by 'blockded' or something similar

I agree with this proposal, we can have OperationState.Blocked in the enum.

[RenanSouza2]

1. In line 341 I wasn't sure in what to include in the error because Pending is no longer in the enum

2. I used the isOperation<...> inside the contract in case of override, let me know what you think

[frangio]

1. In line 341 I wasn't sure in what to include in the error because Pending is no longer in the enum

Interesting. The issue is that cancel can be done in two states, and the TimelockUnexpectedOperationState error only has a single OperationState expected parameter. Should we do the same as with the GovernorUnexpectedProposalState error and use a bitmap? @Amxx @ernestognw What do you think?

[ernestognw]

Interesting. The issue is that cancel can be done in two states, and the TimelockUnexpectedOperationState error only has a single OperationState expected parameter. Should we do the same as with the GovernorUnexpectedProposalState error and use a bitmap? @Amxx @ernestognw What do you think?

I think what we did in GovernorUnexpectedProposalState is the easiest way of expressing multiple enum values so I agree. Alternatively, I'd use the earliest state (eg. blocked) as the required state because it's first in the lifecycle of an operation.

More in favor if a bitmap anyway.

[Amxx]

ok with bitmap

[RenanSouza2]

As of now I just copied the '_encodeStateBitmap' from 'Governor' to 'TimelockController' I would like to unify both implementation, maybe in a file in the utils folder in governance itself, but this woul affect too many files so I want to see yout take on that before doing it

[frangio]

I would like to unify both implementation

I don't think we can do this because it's a different enum type.

[frangio]

I've renamed Blocked to Waiting because I felt Blocked could refer to the predecessor logic.

A few other minor changes as well. This LGTM just need someone else to approve.

[Amxx]

Slight comment about the docs.

Code and Tests are good to me !

[ernestognw]

We're close, just want to confirm why are we removing the virtual from the getters, but that was changed by @frangio

[ernestognw]

As of now I just copied the '_encodeStateBitmap' from 'Governor' to 'TimelockController' I would like to unify both implementation, maybe in a file in the utils folder in governance itself, but this woul affect too many files so I want to see yout take on that before doing it

Let's make an issue for this, it needs discussion but my opinion is that the proposalStatesToBitMap function in test/helpers/governance.js should be in test/helpers/enums.js instead and be renamed to encodedBitmapEnum or similar

[ernestognw]

Just checked back with @frangio on the virtual topic and we agreed the way to override them is by overriding the state getter, which is the source of truth. Also, other functions use the getters instead of state so this is the way to guarantee they behave correctly.