-
Notifications
You must be signed in to change notification settings - Fork 4
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
debonding_delegations: remove id from the table #712
Conversation
cde84d2
to
3234a4c
Compare
delegator = $1 AND delegatee = $2 AND shares = $3 AND debond_end IN ($4::bigint, $4::bigint - 1) | ||
LIMIT 1 | ||
)` | ||
WHERE delegator = $1 AND delegatee = $2 AND shares = $3 AND debond_end IN ($4::bigint, $4::bigint - 1, 0)` |
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.
We could also do debond_end <= $4
, but IMO let's keep it as is, so that any additional issues get noticed
8d75a47
to
dc85fbb
Compare
Please review when you have some time @Andrew7234 @pro-wh @jberci |
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.
I'm okay with this proposed behavior. changes look ok. I'm assuming the DO $$
/ DECLARE ...
work as one would guess
alternative is delete AND shares = $3
and LIMIT 1
so that we process all synthetic debonding delegations together. possibly assert that the sum is equal to the event shares.
did anyone in the explorer team say anything about wanting these to stay separate?
ORDER BY id DESC | ||
LIMIT 1; | ||
|
||
-- Step 3: Insert data from the old table into the new table, merging shares on conflict |
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.
other steps unnumbered?
No, and I also don't see what the benefit would be. I believe it would be confusing since it doesn't match the consensus state where these are merged.
👍 |
dc85fbb
to
0cec5af
Compare
0cec5af
to
fe9a65b
Compare
Fix handling of multiple debonding-delegations ending in the same epoch.
Scenario:
A person undelegates twice from the same delegator, within the same epoch, first X, then Y shares. This ends up in two
DebondingStartEscrowEvent
events with the sameDebondEndTime
.Note that this is likely a common scenario since people tend to first issue a small reclaim escrow as a test, and then soon after a larger reclaim escrow for the rest of the shares.
Oasis-node handling:
Oasis-node internally merges this case into a single debonding-delegation, therefore once the stake is debondend, only a single
ReclaimEscrowEvent
event is returned from oasis-node, with the sum of sharesX+Y
.Nexus handling:
Nexus inserts two debonding delegatinos into the DB (uses a "virtual"
id
field to avoid conflicts) and expects twoReclaimEscrowEvents
one forX
shares and one forY
shares. Since these events are not receieved the debonding delegations do not get cleaned up from the nexus db.Solution:
Remove the "id" field from
chain.debonding_delegation
and handle such debonding delegations ending in the same epoch by merging them.Related mini-fix: There is an additional issue where some debonidng delegations with
debond_end=0
are present in the DB:https://nexus.stg.oasis.io/v1/consensus/accounts/oasis1qpqz2ut6a6prfcjm64xnpnjhsnqny6jqfyav829v/debonding_delegations_to
I believe these might be there because in very past (pre-damask)
DebondingStartEscrowEvent
did not include End time (oasisprotocol/oasis-core#4437). I did not confirm this as a fact, but this seems the most likely explanation and the only reasonable i could think of. So as a mini fix we also handle that case inConsensusDeleteDebondingDelegations
.This issue might not be as problematic in practice, because
fast_sync
-ing over old blocks mitigates this.I think these two issues explain most of the records that are wrongly returned here:
https://nexus.oasis.io/v1/consensus/accounts/oasis1qpqz2ut6a6prfcjm64xnpnjhsnqny6jqfyav829v/debonding_delegations_to
cases with duplicate
debond_end
are explained with the first scenario, and cases withdebond_end=0
the second scenario.However there remain a couple of records that were also not cleaned up and are not duplicated, such as:
These do not have duplicate
debond_end
which would be explained by the first scenario, so it's not obvious to me why these were not cleaned up:^ I have checked a specific example from the above:
staking.escrow.reclaim
event in the db which should have deleted the debonding_delegation (addresses and share numbers match) - there's no duplicate dobnding_delegation heredata.Epoch