-
Notifications
You must be signed in to change notification settings - Fork 126
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
refactor(nexus)!: refactor to move coin locking unlocking logic from axelarnet to nexus #2186
refactor(nexus)!: refactor to move coin locking unlocking logic from axelarnet to nexus #2186
Conversation
ed144a3
to
92df570
Compare
125cd59
to
80879a2
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2186 +/- ##
==========================================
- Coverage 39.89% 39.17% -0.73%
==========================================
Files 373 373
Lines 30857 31676 +819
==========================================
+ Hits 12310 12408 +98
- Misses 17622 18331 +709
- Partials 925 937 +12 ☔ View full report in Codecov by Sentry. |
return err | ||
} | ||
|
||
err = lockableAsset.LockFrom(ctx, types.AxelarIBCAccount) |
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 think this will break in-transit IBC transfers that timeout or have an ack error. Those packets were sent from the escrow accounts, and so the coin would be refunded back to the escrow and the locking here will fail as a result. We can explicitly check what the packet sender was to distinguish this behaviour. But could timeout/ack error be delayed indefinitely? In that case, we might always need to have this fallback
Description
Todos
Steps to Test
Expected Behaviour
Other Notes