Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ProviderContextManager is not concurrency-aware #2348

Open
fubuloubu opened this issue Oct 27, 2024 · 10 comments
Open

ProviderContextManager is not concurrency-aware #2348

fubuloubu opened this issue Oct 27, 2024 · 10 comments

Comments

@fubuloubu
Copy link
Member

Ran into this with a Silverback bot using the new FORK_MODE PR in the Silverback SDK (currently solving with an async concurrency lock)

Not sure this can be resolved without full async support of Ape's network management stack

Copy link

linear bot commented Oct 27, 2024

fubuloubu added a commit to ApeWorX/silverback that referenced this issue Oct 27, 2024
@fubuloubu
Copy link
Member Author

Not quite sure what the issue was, but it lead to weird "trying to fork network mainnet-fork is not possible" or "ecosystem 'base' has no network mainnet-fork-fork" bugs

@antazoey
Copy link
Member

Not quite sure what the issue was, but it lead to weird "trying to fork network mainnet-fork is not possible" or "ecosystem 'base' has no network mainnet-fork-fork" bugs

i can at least improve the error

@antazoey
Copy link
Member

Maybe this helps a little? #2349

@fubuloubu
Copy link
Member Author

Maybe this helps a little? #2349

Yes I believe that will prevent the error, but not totally ideal

I will learn if it works well enough or not when I try to implement backtesting to silverback (at some later date)

for reference, the backtesting mode of silverback takes a range of blocks and executes each block (and relevant event logs/transactions) in an isolated fork that only exists for the span of that one block

@antazoey
Copy link
Member

Wha about a fork-lock for each network so you can't fork until you hold the lock, waiting for other threads / processes to release the lock

@fubuloubu
Copy link
Member Author

Wha about a fork-lock for each network so you can't fork until you hold the lock, waiting for other threads / processes to release the lock

I don't think we need that now with the synchronous version, I will test this fix to see if it works good enough for my use case and get back to you

fubuloubu added a commit to ApeWorX/silverback that referenced this issue Oct 28, 2024
johnson2427 added a commit to ApeWorX/silverback that referenced this issue Nov 24, 2024
* feat(worker): add SILVERBACK_FORK_MODE handler execution context

* refactor: use internal variable for fork detection to prevent scope bug

* fix: block other forks until ApeWorX/ape#2348

* refactor(fork): working with fork fix from ape core

depends: ApeWorX/ape#2349

---------

Co-authored-by: johnson2427 <[email protected]>
@fubuloubu
Copy link
Member Author

This might have been a bit of a false positive, it seems like the provider context manager was not resetting the context stack item when a failure was occuring within the context:

INFO:     Starting 'anvil' process.                                                                                                                                
INFO:     Stopping 'anvil' process.                                                                                                                                
SUCCESS:  exec_event1[...] - 1.150s (8.8%)                 
INFO:     exec_event2[...] - Started                        
INFO:     Starting 'anvil' process.                                                                                                                                
INFO:     exec_block[...] - Started                                
ERROR:    exec_block[...] - 0.000s (0.0%)                          
INFO:     check_logs[...] - Started                                
ERROR:    check_logs[...] - 0.000s (0.0%)                          
INFO:     exec_event1[...] - Started                       
ERROR:    exec_event1[...] - 0.000s (0.0%)                 
INFO:     exec_block[...] - Started                                
ERROR:    exec_block[...] - 0.000s (0.0%)                          
INFO:     check_logs[...] - Started                                
ERROR:    check_logs[...] - 0.000s (0.0%)                          
WARNING:  Runtime error(s) detected, shutting down:                                                                                                                
Unable to fork network 'mainnet-fork'.                                                                                                                             
INFO:     bot_shutdown - Started                                                                                                                                   
ERROR:    bot_shutdown - 0.000s (0.0%)                                                                                                                             
ERROR:    Errors while shutting down:                                                                                                                              
Unable to fork network 'mainnet-fork'.                                                                                                                             
INFO:     Stopping 'anvil' process.                                                                                                                                
ERROR:    exec_event2[...] - 2.500s (19.2%)

@antazoey
Copy link
Member

false positive

I am having trouble seeing any positive here. What is the false-positive part?

@fubuloubu
Copy link
Member Author

"ecosystem 'base' has no network mainnet-fork-fork"

basically, "ecosystem 'base' has no network 'mainnet-fork-fork'" may be a symptom of it not exiting the forked network context when an exception occurs within the forked network context (e.g. executing the silverback event handler function)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants
@fubuloubu @antazoey and others