-
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
Jormungandr m
with getTipId implementation
#321
The head ref may contain hidden characters: "anviking/219/j\u00F6rmungandr-network-2"
Conversation
, mkJormungandr | ||
|
||
-- * Re-export | ||
, BaseUrl (..) |
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.
Some gratuitous re-exports here to avoid the dependencies in .cabal
and import
-statements for these tiny things.
|
||
startNode = do | ||
handle <- async $ launch $ return $ Command | ||
"jormungandr" |
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.
c78975a
to
5793f43
Compare
5793f43
to
586c722
Compare
af72a39
to
5034821
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.
good start
b3eeb5a
to
9b69e6f
Compare
length (transactions b) `shouldBe` 1 | ||
|
||
describe "Error paths" $ beforeAll newClient $ do | ||
it "gets a 'ErrNetworkUnreachable' if jormungandr isn't up (1)" |
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.
For http-bridge
we test this on the NetworkLayer
. I used the Jormungandr
-client here as NetworkLayer
isn't implemented yet.
return $ Left ErrNetworkTipNotFound | ||
x -> do | ||
let ctx = safeLink api (Proxy @GetTipId) | ||
left ErrNetworkTipNetworkUnreachable <$> defaultHandler ctx x |
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 kind-of not comfortable yet with how the servant-client
requests are written, the error handling or the tests, but I'm not sure its worth focusing on, since we already have the same thing going on for the HttpBridge
.
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.
What do you mean by "focusing on" ?
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.
Making an attempt at refactoring.
Not in the pr now, but for instance I find the duplication of parentId (Just count)
off
run (cGetBlockDescendantIds parentId (Just count)) >>= \case
Left (FailureResponse e) | responseStatusCode e == status404 ->
return $ Left ErrGetDescendantsParentNotFound
x -> do
let ctx = safeLink
api
(Proxy @GetBlockDescendantIds)
parentId
(Just count)
left ErrGetDescendantsNetworkUnreachable <$> defaultHandler ctx x
:: Int -> IO (NetworkLayer IO) | ||
newNetworkLayer port = mkNetworkLayer <$> newHttpBridge port | ||
where | ||
newHttpBridge = undefined |
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 the network layer isn't implemented, let's not have it part of the PR at all 👍
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 left it commented still, if you don't mind, as it is the end-goal of the module.
lib/jormungandr/test/integration/Cardano/Wallet/Jormungandr/NetworkSpec.hs
Outdated
Show resolved
Hide resolved
lib/jormungandr/test/integration/Cardano/Wallet/Jormungandr/NetworkSpec.hs
Outdated
Show resolved
Hide resolved
lib/jormungandr/test/integration/Cardano/Wallet/Jormungandr/NetworkSpec.hs
Outdated
Show resolved
Hide resolved
35ad859
to
80bf249
Compare
Jormungandr m
with getTipId and getBlock implementationJormungandr m
with getTipId implementation
4b4392d
to
728d65a
Compare
23a28ce
to
baccb9d
Compare
waitForConnection | ||
:: NetworkLayer IO | ||
-> IO () | ||
waitForConnection nw = loop 20 |
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.
can't we reuse waitForConnection
from Jourmungadr.Network
module ?
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.
Not really. They requests are different* and they are pattern-matching on different errors.
*) Which to me appears like a thing we want: embracing the difference between NetworkLayer
and the potentially underlying Jormungandr
client.
d02c6a6
to
0370c9a
Compare
lib/http-bridge/test/integration/Cardano/Wallet/HttpBridge/NetworkSpec.hs
Show resolved
Hide resolved
7d1343b
to
befdada
Compare
-- | Tries to waits 20 s, until 'networkTip networkLayer' succeeds. | ||
waitForConnection | ||
:: NetworkLayer IO | ||
-> Int -- ^ Number of retries / timeout in seconds |
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 is exactly what Quantity
is for! To convey this kind of information 😉 Every time you see yourself putting a comment to explain a What
(and not a Why
), ask yourself if you couldn't instead craft a better type that answers it.
Also, the comment seems to be a lie.
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.
Also, the comment seems to be a lie.
Fair point.
This is exactly what Quantity is for!
If we do retry
it won't matter, but:
This is exactly what Quantity is for!
Hmmmmmmm.… 🤔
As long as we don't just
f (Quantity 1000000)
sure, maybe.
Replacing the stock threadDelay
with a typed version — everywhere — might be an idea too.
TIO.putStrLn "[INFO] waiting for connection to the node..." | ||
threadDelay 1000000 | ||
loop (retries - 1) | ||
Left e -> throwIO e |
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'd suggest to simply use functions from retry
here, which already encapsulate nicely this logic. This would also allow to simply take a retryPolicy
as an argument (instead of an untyped Int
) and, to provide a default policy next to the waitForConnection
function for an easy usage:
waitForConnection defaultPolicy
In testing, this would allow to pass in a different policy for which the cumulative delay can be just 500ms or so, to avoid hanging for nothing in tests.
ErrNetworkTipNetworkUnreachable _ -> True | ||
_ -> False | ||
|
||
it "returns when the network becomes availible" $ do |
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.
Typo available
-> available
-- returns within (3s + 3s extra) | ||
res <- race | ||
(threadDelay 6000000) | ||
(waitForConnection c 20) |
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.
woudl be nice to be consistent with variable names. c
is called nw
in the previous test and in the helper function. Try to pick a name, and stick to it 👍
-- Start the bridge after 3s, and make sure waitForConnection | ||
-- returns within (3s + 3s extra) | ||
res <- race | ||
(threadDelay 6000000) |
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.
Avoid "magic numbers" and use named constant -> let sixtySeconds = 60000000
etc .. At the very least, use a numeric separator to make thousands more obvious.
lib/http-bridge/test/integration/Cardano/Wallet/HttpBridge/NetworkSpec.hs
Show resolved
Hide resolved
handle <- async . launch . return | ||
$ httpBridgeWithSetup (threadDelay 3000000) | ||
-- Start the bridge after 3s, and make sure waitForConnection | ||
-- returns within (3s + 3s extra) |
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.
Why do we need this extra 3s ? Can't we just start the bridge and call wait for connection.. That's how we would normally use it, isn't it ?
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 to check that waitForConnection
did in-fact return within a reasonable time, not just that it returned. Overkill?
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.
Hmmmm. I still don't get it? Also, are we sure that 3 seconds is indeed enough in every environment? I'd rather just wait for connection, and verify that it resolve. If it always return within 3 seconds, then why wait for 20s
in the implementation? If we are ready to wait up-to 20s that's what we should be testing here and this should never throw.
TIO.putStrLn "[INFO] waiting for connection to the node..." | ||
threadDelay 1000000 | ||
loop (retries - 1) | ||
| otherwise -> throwIO e |
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 function already exists in Cardnao.Wallet.Network
. What's the rationale for having both?
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.
To have it for both Jormungandr
, and NetworkLayer
. (Ignoring HttpBridge as I haven't seen a need for it)
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.
But what's the need for the one in Jörmungandr? Why isn't it possible to get the same "feature" using only the NetworkLayer
? What does it bring us to specialize this to Jormungandr
?
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 decide to not have integration tests for Jormungandr
. Then we wouldn't need another waitForConnection
. I don't see why we shouldn't have though.
If we instead were to here implement and test networkTip networkLayer
, that would rely on both jormungandr getTipId
(implemented) and getBlock
(not implemented), as getTipId
doesn't return a BlockHeader
.
59bf517
to
173ab2e
Compare
173ab2e
to
b50c21b
Compare
Following discussion with @KtorZ I've now:
And, well, we use the |
handle <- async . launch . return | ||
$ httpBridgeWithSetup (threadDelay 3000000) | ||
-- Start the bridge after 3s, and make sure waitForConnection | ||
-- returns within (3s + 3s extra) |
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.
Hmmmm. I still don't get it? Also, are we sure that 3 seconds is indeed enough in every environment? I'd rather just wait for connection, and verify that it resolve. If it always return within 3 seconds, then why wait for 20s
in the implementation? If we are ready to wait up-to 20s that's what we should be testing here and this should never throw.
-- >>> mgr <- newManager defaultManagerSettings | ||
-- >>> j = mkJormungandrLayer mgr (BaseUrl Http "localhost" 8080 "") | ||
-- >>> runExceptT $ getTipId j | ||
-- Right (BlockId (Hash {getHash = "26c640a3de09b74398c14ca0a137ec78"})) |
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.
👍
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.
Also, are we sure that 3 seconds is indeed enough in every environment?
I am sure my machine will be exceptional :)
2e21d4e
to
c9958e2
Compare
c9958e2
to
56db060
Compare
Issue Number
#219
Overview
Cardano.Wallet.Jormungandr.Api
, and temporarily removed all endpoints from theApi
butGetTipId
Jörmungandr m
client inCardano.Wallet.Jormungandr.Network
getTipId
, testing that it works, and that it can returnLeft ErrNetworkUnreachable
. 404 is not a possibility .waitForConnection
to node at launchComments
Relevant API definition: