-
-
Notifications
You must be signed in to change notification settings - Fork 492
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
Various changes centered around fixing 5432 #6071
Conversation
Oh goody. Tests failed here and there. Let's see if this makes sense to continue looking into. |
Codecov Report
@@ Coverage Diff @@
## develop #6071 +/- ##
===========================================
- Coverage 79.72% 79.36% -0.36%
===========================================
Files 1092 1092
Lines 115017 115054 +37
Branches 10071 10073 +2
===========================================
- Hits 91693 91313 -380
- Misses 21623 22053 +430
+ Partials 1701 1688 -13
Flags with carried forward coverage won't be shown. Click here to find out more.
|
e2b45ee
to
f396c2e
Compare
Achieved by using tuples. Also using Sequence as type in all relevant functions, which is an immutable sequence. Matches either tuple or list or any other sequence used immutably.
Removed the lock in rotki#6067 It was though the error was only in Detach which needed the transaction lock that was introduced there. But unfortunately a multiple attach can also result in an error so we need the lock too
Add a test that reliably reproduces the flaky Error binding parameter 0 - probably unsupported type.
This is a "temporary fix" for the error binding parameter 0 flaky error as seen in rotki#5432. If I understand it correctly the bug is in the python sqlite drivers and as such this is just a patch until it's solved properly. We have a test to reproduce so we should periodically check as we upgrade python versions to see if this is fixed and then we can revert.
I am gonna merge this, though there is still a known issue with |
@@ -110,8 +111,7 @@ def get_accounts_having_proxy(self) -> dict[ChecksumEvmAddress, ChecksumEvmAddre | |||
|
|||
with self.node_inquirer.database.conn.read_ctx() as cursor: | |||
accounts = self.node_inquirer.database.get_blockchain_accounts(cursor) | |||
eth_accounts = accounts.eth | |||
mapping = self.get_accounts_proxy(eth_accounts) | |||
mapping = self.get_accounts_proxy(accounts.get(self.node_inquirer.blockchain)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was another bug I found. We always were taking eth accounts here irrespective of the evm chain type
rotki/test-caching/tree/small_shit was successfully merged |
BlockchainAccounts lists are now tuples -- immutable
Also using Sequence as type in all relevant functions, which is an
immutable sequence. Matches either tuple or list or any other sequence
used immutably. As these should not be modified at any point apart from when reading from the DB or adding/removing an address to/from the DB.
This was all done in order to try and reproduce and find the root cause for this: #5432
But apart from liquity module where there was addresses being added, but on a carefully made copy I did not see anything else where mypy had warnings.
Evm chain bug
Fix bug where eth_accounts were always used irrespective of chain id
Reproduce and "fix" 5432
Finally reproduced 5432 reliably in a test and provided a bad fix. For more info read the issue.