Replaced rc by arc in daemon

[Kayanski]

This PR aims at replacing RC by ARC to be able to send a daemon between threads

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Pages

Latest commit:	f6e4393
Status:	🚫  Build failed.

View logs

[codecov]

Codecov Report

Attention: 9 lines in your changes are missing coverage. Please review.

Comparison is base (9998ad5) 66.1% compared to head (f6e4393) 65.9%.
Report is 3 commits behind head on main.

Additional details and impacted files

Files	Coverage Δ
cw-orch-daemon/src/builder.rs	87.5% <100.0%> (ø)
cw-orch-daemon/src/core.rs	59.6% <ø> (ø)
cw-orch-daemon/src/sender.rs	62.0% <100.0%> (ø)
cw-orch-daemon/src/sync/core.rs	31.5% <ø> (ø)
packages/cw-orch-core/src/environment/state.rs	47.6% <57.1%> (-23.9%)	⬇️

... and 3 files with indirect coverage changes

[CyberHoward]

Nice! What's the use-case you're going for?

[CyberHoward]

Although you could get into trouble with this... I think you need to use Mutex instead of Arc and preferably update the file mutations to use async functions!

With Arc you don't have inner mutability type-checked. I.e. you can have two threads that read/write the same file as the same time and that will screw things up for you. If you use Mutex you can prevent that from happening.

[Kayanski]

Nice! What's the use-case you're going for?

It's for use with an axum server ! Using the daemon to be able to query chain information and depending on the arriving transactions, give a fee grant to the user for on-boarding the chain.
--> https://github.com/CavernPerson/onboarding-api/

I'm wrapping my Daemon inside a Mutex to avoid simultaneous mutations

[CyberHoward]

Nice! What's the use-case you're going for?

It's for use with an axum server ! Using the daemon to be able to query chain information and depending on the arriving transactions, give a fee grant to the user for on-boarding the chain. --> https://github.com/CavernPerson/onboarding-api/

I'm wrapping my Daemon inside a Mutex to avoid simultaneous mutations

In that case it would still be better to wrap the required types internally. The type should be safe to use as-is.
You'll also have to think about the account_sequence because if you have multiple threads doing txs with the same sender it will error on an account sequence mismatch.

[Kayanski]

Nice! What's the use-case you're going for?

It's for use with an axum server ! Using the daemon to be able to query chain information and depending on the arriving transactions, give a fee grant to the user for on-boarding the chain. --> https://github.com/CavernPerson/onboarding-api/
I'm wrapping my Daemon inside a Mutex to avoid simultaneous mutations

In that case it would still be better to wrap the required types internally. The type should be safe to use as-is. You'll also have to think about the account_sequence because if you have multiple threads doing txs with the same sender it will error on an account sequence mismatch.

Will update with Mutex then !
account sequence handles itself automatically if you use a mutex on the sender !

[CyberHoward]

Nice! What's the use-case you're going for?

It's for use with an axum server ! Using the daemon to be able to query chain information and depending on the arriving transactions, give a fee grant to the user for on-boarding the chain. --> https://github.com/CavernPerson/onboarding-api/
I'm wrapping my Daemon inside a Mutex to avoid simultaneous mutations

In that case it would still be better to wrap the required types internally. The type should be safe to use as-is. You'll also have to think about the account_sequence because if you have multiple threads doing txs with the same sender it will error on an account sequence mismatch.

Will update with Mutex then ! account sequence handles itself automatically if you use a mutex on the sender !

How does it handle it automatically? The account sequence is only incremented once a tx is included in a new block so an attept to put multiple txs into the same block will fail.

[CyberHoward]

There's a retry strategy but that's highly inefficient.

[Kayanski]

How does it handle it automatically? The account sequence is only incremented once a tx is included in a new block so an attempt to put multiple txs into the same block will fail.

Because the Mutex is around the Daemon, it will only unlock it when the transaction has been included in a block (after awaiting the tx), ie after the next block, so the account sequence is updated and everything works prefectly

[CyberHoward]

How does it handle it automatically? The account sequence is only incremented once a tx is included in a new block so an attempt to put multiple txs into the same block will fail.

Because the Mutex is around the Daemon, it will only unlock it when the transaction has been included in a block (after awaiting the tx), ie after the next block, so the account sequence is updated and everything works prefectly

If you do it around the daemon sure but then what's the benefit to having it multi-threaded if you can't execute txs in parallel? You could include the account seq in the Sender object itself and have it incremented on every submitted tx. Then you don't need to lock the whole daemon object while waiting for a response.

[CyberHoward]

Actually I think it's not the Sender that needs to be Mutex it's only the sender's account sequence.