chore: upgrade to stable toolchain

[ghost]

The issue involving wasm contract builds for Rust toolchain 1.70 and later: near/nearcore#9143 has been resolved
Should be ok to update the toolchain.

Are we updating to toolchain 1.70 or ok to use stable?

[ghost]

@frol This is for updating the toolchain to stable. The wasm contract should now be buildable with the latest Rust Stable Version

[ghost]

Quick question, I have updated the build.rs file to use sandbox with a newer commit from the nearcore repo, and I changed install instead I used install_with_version. Is this ok ? or shall I update the sandbox utils crate ?

[frol]

Other than the comment above, we are good to go. Given that it will require near_sandbox_utils publishing, I think we can use install_with_version here for the time being, but let's pick the most recent stable release in nearcore instead of some random recent commit.

[mrLSD]

@shariffdev @frol
Currently when we use workspace-rs that issue near/nearcore/issues/9143 is still reproducible.
For example for this aurora-is-near/aurora-engine/pull/832.

Does this PR solve issue also for nightly (current) versions?

[ghost]

@frol if we use the most recent stable release which is 1.35, it doesn't include the fixes for this #272, It is either I use this recent commit or edit the sandbox and use a more recent hash commit

Or we can forgo this issue #272 entirely, until it is included in the next release.

[frol]

I see, indeed, I hoped there was another release since that time. I think we should be fine using more recent nearcore snapshot for now as workspaces-rs only needs to run it in a local node mode, so there is no risk of incompatibility, insecurity, or instability of it. That said, probably sandbox-utils does not need to be updated to some random hash commit, let's upgrade it to the most recent release of nearcore while workspaces-rs would use some custom commit hash.

[ghost]

Working on the sandbox utils now.

[ghost]

@shariffdev @frol Currently when we use workspace-rs that issue near/nearcore/issues/9143 is still reproducible. For example for this aurora-is-near/aurora-engine/pull/832.

Does this PR solve issue also for nightly (current) versions?

Yes, this should solve the issue you mentioned. This crate now uses a a newer sandbox which has the fix for this near/nearcore/issues/9143

[mrLSD]

@shariffdev this PR was merged. But when I link the latest main hash 8d93197 as a dependency, near/nearcore/issues/9143 is still reproducible for stable and nightly. Any ideas?

[ghost]

@shariffdev this PR was merged. But when I link the latest main hash 8d93197 as a dependency, near/nearcore/issues/9143 is still reproducible for stable and nightly. Any ideas?

@mrLSD I've looked into this with an example contract in a fresh project dir using the stable toolchain and things are fine. Could you have missed something?

[mrLSD]

Could you have missed something?

@shariffdev

1. For the building contract I used near-sdk = "4.1.1"
2. For tests: workspaces = { git = "https://github.com/near/workspaces-rs.git", rev = "8d93197" }
3. rustc 1.72.0 (5680fa18f 2023-08-23)

All tests failed with Deserialization error.

[ghost]

@mrLSD Try doing a cargo clean I recreated your issue and that did it for me

[mrLSD]

@shariffdev
cargo clean && rm -rf target/ - doesn't work.

status: Failure(ActionError(ActionError { index: Some(0), kind: FunctionCallError(CompilationError(PrepareError(Deserialization))) })),

[ghost]

I'm out of ideas but still looking into it. Is there a chance the code is open and I can take a look at it?

[mrLSD]

@shariffdev
It fails here

How it was tested:

1. Toolchain set to stable (or nightly-2023-08-24)
2. Set Cargo.toml: workspaces = { git = "https://github.com/near/workspaces-rs.git", rev = "8d93197" }
3. cargo update
4. Run build and tests: make test

I tested for our projects:

https://github.com/aurora-is-near/aurora-eth-connector/tree/master/eth-connector-tests

https://github.com/aurora-is-near/aurora-engine/tree/develop/engine-tests

Same issues.

[ghost]

I have created a new issue for better visibility on this problem you are facing @mrLSD

We can move the discussion over there