-
-
Notifications
You must be signed in to change notification settings - Fork 133
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
Comments
Not quite sure what the issue was, but it lead to weird "trying to fork network |
i can at least improve the error |
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 |
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 |
* 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]>
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:
|
I am having trouble seeing any positive here. What is the false-positive part? |
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) |
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
The text was updated successfully, but these errors were encountered: