Post Code Complete test plan for EC-Changes

[toliaqat]

After the code-complete, we need to verify A3P and Testnets, before we can be confident to deploy this on the mainnet. Let's list down verifications that we need to do and in what environments.

A3P:

see below

Emerynet:
see below

Mainfork/Ollinet:
none

Devnet (if needed):
none

[otoole-brendan]

@frazarshad @rabi-siddique thinking more on this, it's going to be tricky to validate the changes work on Devnet + emerynet since we have our own gov accounts there (and these are different to what the EC members use on mainnet). I guess we can start from a place of have some arbitrary EC members addresses set up before upgrade, then have it replaced with new members during upgrade then verify that the old members can't vote but the new members can (After they accept) - that's presumably how you've been testing so far right?

[otoole-brendan]

@frazarshad and @rabi-siddique we discussed how we'd test this. For the testnet core eval we'll need to configure 4 gov accounts (3 existing and 1 new account we'll need to create).

Since some scripts and tests use Gov1 and Gov2 let's ensure these two Gov accounts continue to be in the new committee for testing. Let's revoke voting rights for Gov3 and then lets add a new account Gov 4 to the committee and ensure it can propose and vote

Gov 1 - Keep (Propose and Vote)
Gov 2 - Keep (Propose and Vote)
Gov 3 - Revoke
Gov 4 - New (Propose and Vote)

[rabi-siddique]

that's presumably how you've been testing so far right?

@otoole-brendan Yes

[rabi-siddique]

A3P:
[list down verification steps and any e2e tests we will run for EC-Change verification]

Currently, we have a two-member committee for A3P, which includes the wallets gov1 and gov2. When the core eval for replacing the electorate is passed on A3P, the electorate has only gov1 as a member. gov2 has been removed from the electorate and also from the highPrioritySenders list.

@otoole-brendan @dckc, is this okay? Or should we consider introducing a new incoming member to the electorate?

[rabi-siddique]

Mainfork/Ollinet:
[list down verification steps and any e2e tests we will run for EC-Change verification]

Emerynet:
[list down verification steps and any e2e tests we will run for EC-Change verification]

Devnet (if needed):
[list down verification steps and any e2e tests we will run for EC-Change verification]

In the current testnet setup, the EC members are:

• gov1
• gov2
• gov3

After updating the electorate:

• gov1 and gov2 are invited to join the new committee and charter.
• gov3 is removed from the electorate.
• A new member, gov4, is introduced and becomes part of the electorate.

[rabi-siddique]

For E2E tests, we already have tests in econ-gov, which are catered towards A3P. @otoole-brendan , are there plans to introduce e2e tests specifically for the testnets? Implementation seems feasible, though we'll need to consider differences like how invitation acceptance works across different environments.

For A3P, once the chain is started, it guarantees the presence of committee and charter invitations in the econ-gov UI. For testnets, it seems that accepting invitations is a one-time thing. This difference suggests we might need to revise our testing approach to account for how testnets handle invitations. Maybe we could manually accept the new committee and charter invitations on testnets and design tests to propose changes to contracts using gov3?

[dckc]

This discussion looks like it's about pre-code-complete stuff; i.e.

• Update hardcoded EC addresses with newly elected committee members #10194

[otoole-brendan]

For E2E tests, we already have tests in econ-gov, which are catered towards A3P. @otoole-brendan , are there plans to introduce e2e tests specifically for the testnets? Implementation seems feasible, though we'll need to consider differences like how invitation acceptance works across different environments.

For A3P, once the chain is started, it guarantees the presence of committee and charter invitations in the econ-gov UI. For testnets, it seems that accepting invitations is a one-time thing. This difference suggests we might need to revise our testing approach to account for how testnets handle invitations. Maybe we could manually accept the new committee and charter invitations on testnets and design tests to propose changes to contracts using gov3?

@rabi-siddique it seems excessive to test EC accounts accepting new committee invitations for E2E tests. I think the most important thing is we want to ensure we're able to test the EC changes broadly on a testnet which is achieved using those 4 gov accounts and changes we're described above.

One thing I'm not sure on is testing on A3P. So we use only 2 Gov accounts for testing on A3P but 3 (soon to be 4) on testnets?

[rabi-siddique]

I think the most important thing is we want to ensure we're able to test the EC changes broadly on a testnet which is achieved using those 4 gov accounts and changes we're described above.

Agreed. We can introduce new tests to propose parameter changes using gov4(New incoming member of the committee), and also utilize gov4 when voting on these changes.

[rabi-siddique]

One thing I'm not sure on is testing on A3P. So we use only 2 Gov accounts for testing on A3P but 3 (soon to be 4) on testnets?

@otoole-brendan Yes, that's correct. For A3P, we have two governance wallets, gov1 and gov2. When we establish a new committee in the A3P e2e tests, we only send an invitation to gov1. Because of that, the new committee consists of gov1 only, and gov2 is no longer a member of the committee.

[dckc]

current status and proposed plan:

A3P tests

2024-10-24T14:51:43.3360501Z #48 39.37 2024-10-24T14:51:43.153Z SwingSet: vat: v1: GovReplaceCommiteeAndCharter committeeSize 3
2024-10-24T14:58:24.5880997Z   ✔ should be able to view the new accepted invitations (178ms)
2024-10-24T15:12:38.6889437Z   ✔ economic committee can make governance proposal and vote on it (24.4s)

ci log

Corresponding Functional Requirements

1. The community must be able to replace the EC slate via BLD staker governance (governance committee membership must be replaceable)
2. It must be able to support a 3 member economic committee
3. Where a 3 member committee, the quorum threshold must be 2 of 3. (pending)
4. A newly elected EC slate must replace/supersede the old EC slate
5. The newly elected EC members must be sent a new invitation(s) to their provided addresses
6. The newly elected EC members must accept their new charter invitations in order to be able regain their governance privileges
7. The newly elected EC must be able to govern by proposing and voting through changes

FR8 is covered in a bootstrap test

FR9 is covered in a ui e2e test
FR10 is covered by a number of ui e2e tests

[dckc]

discussed with @otoole-brendan, @rabi-siddique, and @frazarshad :

Emerynet

1. Some manual smoke testing by @otoole-brendan

2. After merging updates, run dapp-econ-gov ui e2e tests on emerynet (@rabi-siddique )

Mainfork/Ollinet

none

Devnet

none

[dckc]

I also added a link from the runbook.