[indexer] Get ready to nearcore 1.25.0

[khorolets]

TL;DR: 9b3d6ba551f561a028f0216051e031bc2ba0c6b7

• testnet Feb 15, 2022 protocol upgrade is about to happen
• mainnet Mar 16, 2022 (validators are asked to upgrade on Mar 21, 2022, so the protocol version upgrade is expected to land on Mar 22-23)

Releases Rollout Announcement

🔔 Based on community feedback, we are moving planned nearcore releases from Mondays to Wednesdays. Non-validator nodes may upgrade on Wednesday immediately after the official announcement. Validator nodes may upgrade the following Monday, such that the network protocol switch occurs in the middle of the work week. We hope this change makes a quality of life improvement to our node operators to avoid working weekends.

https://t.me/near_validators/5147

1.25.0-rc.1

Commit hash 539f254f793a3324a29e6e97e3b804b9fa4f27a2
Expected issues

This release will make a protocol upgrade, your nodes might get stuck if you don't upgrade them before the protocol upgrade happens.

1. Breaking changes on NEAR Indexer Framework side. Now when you create an instance of near_indexer::Indexer you get Result enum and you need to handle it.

BEFORE

let indexer = near_indexer::Indexer::new(indexer_config);

AFTER

let indexer = near_indexer::Indexer::new(indexer_config)
    .expect("Failed to initiate Indexer");

2. nearcore rust-lang version used is bumped to 1.58.1
3. Version of itertools has changed from 0.9.0 to 0.10.3

If you don't use itertools directly of any other packages but get error about dependency versions.
Replace the Cargo.lock in your project with the Cargo.lock from the release and run cargo check or cargo build --release again.

Reference have a look at how we made it on NEAR Indexer for Explorer

Feel free to leave your questions in the comments below.

1.25.0-rc.2

No need to upgrade indexers

1.25.0-rc.3

No need to upgrade indexers

1.25.0 release

Commit hash 9b3d6ba551f561a028f0216051e031bc2ba0c6b7

Expected issues: read 1.25.0-rc.1 section

[maoueh]

When is the protocol upgrade happing on NEAR Testnet exactly? Like yesterday? This was posted 9 hours ago, can we get a bit of leeway to upgrade nodes.

At least it does not seem to broken just right now on testnet.

[khorolets]

@maoueh

At least it does not seem to broken just right now on testnet.

This changes in a moment.

When is the protocol upgrade happing on NEAR Testnet exactly?

I'm sorry, I'm not aware of the ETA. Usually, it takes a couple of days. It depends on the number of validators in the network who have upgraded to a newer version.

@janewang do we have any ETA on when protocol will upgrade on testnet?

[janewang]

@khorolets We don't have exact time but we built an upgrade alert here for the network upgrade ratio. Once 80% of validator nodes upgrade, the protocol will upgrade in 2 epoches.
https://docs.near.org/docs/develop/node/maintenance/upgrade_alert

[maoueh]

Ok I better understand now the challenge here. Just to be sure I got. Assuming we have version 1.24.0 active today and the 1.25.0-rc.1.

While not 80% of the node have updated, version 1.24.0 and 1.25.0-rc.1 works as expected. When 80% have finally updated, 1.24.0 will stop syncing properly. Correct?

Is it 80% of the validators or 80% of the nodes in the network?

Two observations I could make:

• If it's 80% of the validator, could we maybe split the upgrade in 2 phases. 1 phases for "syncing nodes" that tracking the network and then another one for validators. This way it will give us leeway to update API nodes.
• When this post is made, would it possible to put the upgrade day a few days after this post is created? For example, this post was created yesterday, maybe upgrade could have been Feb 17 or Feb 18, that will let a bit of leeway to update the dependency, prepare release, etc.

[janewang]

@maoueh You understand it correctly. Right now validator nodes are held back for about 3 days. Say we release on Monday, we ask validators to hold back upgrading till Wednesday and the network is upgrade by Thursday (plus 2 epochs) at the earliest.

We are evaluating a few options to make the network upgrade more deterministic by timestamp or block height. The protocol upgrade could be at the specific time (giving sufficient time for other parties) when we run a check to see if 80% validator nodes are already upgrade and switch over, and not before when validator nodes non-deterministically reached 80% upgrade ratio.

[tifrel]

@janewang Is there a public endpoint to see the upgrade percentage?

[janewang]

@tifrel Unfortunately, we don't have a public endpoint right now.

[maoueh]

For the itertools dependency problem, instead of replacing the Cargo.lock completely, itertools at version 0.10.3 can be requested in the Cargo.toml directly, we fixed it with:

# Added to get rid of a dependencies error even if we do not use it directly
itertools = "0.10.3"

[khorolets]

Good point. But if you don't want to have itertools in your explicit dependency list the Cargo.lock trick is always there.