-
Notifications
You must be signed in to change notification settings - Fork 23
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
chore: Sync position with dlc channel state #1298
Conversation
4a5e66d
to
a285949
Compare
a285949
to
9db92f8
Compare
9db92f8
to
38bf276
Compare
builder: (context) { | ||
TaskStatus status = context.watch<RecoverDlcChangeNotifier>().taskStatus; | ||
|
||
// todo(holzeis): Reusing the order submission status dialog is not nice, but it's actually suitable for any task execution that has pending, |
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.
is there a particular reason you're not just keeping this as normal TODO
s ? e.g. do you have a commit hook that checks for these specifically?
on my end is worse than normal TODO
as it's harder to spot it both with the naked eye when reading the code and also doesn't get picked up by my IDE which e.g. automatically shows me TODOs that are not on the main branch.
also, one can see the author of a TODO with regular git blame
.
if you don't mind either way, please consider the points above 🙏
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 I've seen it on other projects (rust-dlc
?) done like that - and I like it. It shows ownership of the todo. git blame
is not always trustworthy as moving code will easily change that.
I like doing it like that and I don't think it hurts, but if you are feeling strongly about it I can change it to a regular todo.
fyi: my IDE is highlighting these todos the same way its highlighting any other todo.
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.
if you are using this plugin https://github.com/alphapapa/magit-todos, I guess the only issue was that I did not capitalized the keyword.
Items in KEYWORD(username): format are also read
I have capitalized all fixmes and todos, let me know if this is working for you now.
38bf276
to
28224b1
Compare
28224b1
to
e0c021e
Compare
6ae6404
to
7fbb639
Compare
e0c021e
to
26cd809
Compare
7fbb639
to
bc18260
Compare
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.
LGTM, but I would really appreciate some tests. I think we can fairly simply define a pure function that can be unit tested. Then it wouldn't be so important to review the tricky logic.
@@ -32,8 +32,14 @@ pub enum Event { | |||
#[frb] | |||
#[derive(Clone)] | |||
pub enum BackgroundTask { |
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.
❓ The name BackgroundTask
doesn't make sense to me atm. These are just messages, right?
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.
well, they are messages tasks executed in the background 😅. Any suggestion for a better name? 🙂
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 it's fine looking at it again.
bc131ad
to
fe955b8
Compare
@luckysori @klochowicz I have addressed your feedback and also added unit tests. de37a34#diff-817ef51e9e3a8d899433cfad50ab3e46d729def3e1bd663f5d5614a8a468e174 Please have another look. |
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.
LGTM!
switch (widget.type) { | ||
case OrderSubmissionStatusDialogType.pendingSubmit: | ||
case OrderSubmissionStatusDialogType.successfulSubmit: | ||
switch (widget.status) { | ||
case TaskStatus.pending: | ||
return "Pending"; | ||
case OrderSubmissionStatusDialogType.filled: | ||
case TaskStatus.success: | ||
return "Success"; | ||
case OrderSubmissionStatusDialogType.failedSubmit: | ||
case OrderSubmissionStatusDialogType.failedFill: | ||
case TaskStatus.failed: | ||
return "Failure"; |
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.
the way how it made the widget simpler confirms your initial intuition that it could be a more general-purpose widget ❤️
bbd5ca2
to
f3fa8db
Compare
fe955b8
to
e37bf12
Compare
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.
Thank you for adding the tests!
@@ -32,8 +32,14 @@ pub enum Event { | |||
#[frb] | |||
#[derive(Clone)] | |||
pub enum BackgroundTask { |
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 it's fine looking at it again.
Before we got confusing log messages with "received unexpected event".
e37bf12
to
0067166
Compare
This change will do the following things depending on the dlc channel state and position. - DLC Channel in state `Signed` but no position: Create position from `filling` order. - DLC Channel in state `OffChainClosed` and a position exists. Delete the position. - DLC Channel in state `CloseOffered` or `CloseAccepted`: Inform the UI that the dlc channel is recovering. - DLC Channel in state `Offered`, `Accepted` or `Finalized`: Inform the UI that the dlc channel is recovering. - DLC Channel in any other state but with position: Delete position the channel might have been force closed.
The `OrderSubmissionStatusDialog` is actually useful for any kind of task showing a pending, failed or success state.
0067166
to
f33faa5
Compare
This change will sync the position to the dlc channel state in the following scenarios
Signed
but no position: Create position fromfilling
order.OffChainClosed
and a position exists. Delete the position.CloseOffered
orCloseAccepted
: Inform the UI that the dlc channel is recovering.Offered
,Accepted
orFinalized
: Inform the UI that the dlc channel is recovering.Recover from scenarios 1 and 2.
I have commented the part of the code that should update the position state, so that the spinner will go forever when opening or closing a position.
Simulator.Screen.Recording.-.iPhone.14.Pro.-.2023-09-14.at.14.16.34.mp4
Recover from scenarios 3 and 4.
Simulator.Screen.Recording.-.iPhone.14.Pro.-.2023-09-14.at.13.50.40.mp4
Interestingly this takes quite a long time to complete. I did at a 5 seconds sleep for the channel to get ready with 4a5e66d, but it still takes far too long.
Manually calling the
period_check
to process any pending actions immediately "fixed" that issue, but should be fixed inrust-dlc
. There is no reason why we should check every 30 seconds if pending actions need to be processed as pending action can only ever happen after channel reestablishment.Recover from scenario 5 (force closure)
Simulator.Screen.Recording.-.iPhone.14.Pro.-.2023-09-14.at.14.24.45.mp4
fixes #1273
fixes #1271