-
Notifications
You must be signed in to change notification settings - Fork 217
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
[ADP-3479] Amend wallet page to host wallet status #4865
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -90,6 +90,7 @@ import Cardano.Wallet.Network.Checkpoints.Policy | |
import Control.Tracer | ||
( Tracer | ||
, contramap | ||
, traceWith | ||
) | ||
import Data.Bifunctor | ||
( first | ||
|
@@ -175,12 +176,14 @@ readWalletState WalletInstance{walletState} = | |
|
||
-- | Initialize a new wallet in the given environment. | ||
withWalletInit | ||
:: WalletEnv IO | ||
:: Tracer IO () -- wallet tip changes | ||
-> WalletEnv IO | ||
-> Credentials | ||
-> Word31 | ||
-> (WalletInstance -> IO a) | ||
-> IO a | ||
withWalletInit | ||
wtc | ||
env@WalletEnv | ||
{ bootEnv = WalletBootEnv{genesisData} | ||
, .. | ||
|
@@ -194,23 +197,26 @@ withWalletInit | |
credentials | ||
knownCustomerCount | ||
genesisData | ||
withWalletDBVar env walletState action | ||
withWalletDBVar wtc env walletState action | ||
|
||
-- | Load an existing wallet from the given environment. | ||
withWalletLoad | ||
:: WalletEnv IO | ||
:: Tracer IO () -- wallet tip changes | ||
-> WalletEnv IO | ||
-> (WalletInstance -> IO a) | ||
-> IO a | ||
withWalletLoad env@WalletEnv{..} action = do | ||
withWalletLoad wtc env@WalletEnv{..} action = do | ||
walletState <- DBVar.loadDBVar store | ||
withWalletDBVar env walletState action | ||
withWalletDBVar wtc env walletState action | ||
|
||
withWalletDBVar | ||
:: WalletEnv IO | ||
:: Tracer IO () -- wallet tip changes | ||
-> WalletEnv IO | ||
-> DBVar.DBVar IO Wallet.DeltaWalletState | ||
-> (WalletInstance -> IO a) | ||
-> IO a | ||
withWalletDBVar | ||
wtc | ||
env@WalletEnv{bootEnv = WalletBootEnv{logger, networkEnv}} | ||
walletState | ||
action = do | ||
|
@@ -228,7 +234,7 @@ withWalletDBVar | |
[ walletTip | ||
, Read.GenesisPoint | ||
] | ||
, rollForward = rollForward w | ||
, rollForward = rollForward w wtc | ||
, rollBackward = rollBackward w | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For the sake of showing sync progress this is probably what we want (or practically what we want), but techincally the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes I cut that corner for the demo. I feel like we can keep it like this for now.
|
||
} | ||
|
||
|
@@ -294,17 +300,19 @@ getAllDeposits w i = | |
|
||
rollForward | ||
:: WalletInstance | ||
-> Tracer IO () -- wallet tip changes | ||
-> NonEmpty (Read.EraValue Read.Block) | ||
-> tip | ||
-> IO () | ||
rollForward w blocks _nodeTip = do | ||
rollForward w wtc blocks _nodeTip = do | ||
timeFromSlot <- slotResolver w | ||
onWalletState w | ||
$ Delta.update | ||
$ Delta.Replace | ||
. Wallet.rollForwardMany | ||
timeFromSlot | ||
blocks | ||
traceWith wtc () | ||
x <- readWalletState w | ||
x `seq` pure () | ||
|
||
|
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.
Was curious: did you consider using
TVar IO ()
or I guessTVar IO WalletState
? (edit: meant to be used asSTM ()
orSTM WalletState
, yes, probably that's the better spelling of them)And taking the latter one step further, we get the question whether we could have
DBVar STM WalletState
instead of inIO
🤔 cc @HeinrichApfelmusThere 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.
For the way it is used ATM, the STM composability is not a requirement. We are serving this signal as a long poll over the network. It's also dangerous for the signal producer which could get stuck (in theory) by other concurrent producers.
STM ()
could be better ? But I would not dig into that until we have a real need.About dangers IIRC there is a fan out in the code that ensure the tracer never locks at the expense of dropping events.