Skip to content
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

RPC doesn't start if blocks are not being generated #9

Open
jholdstock opened this issue Apr 26, 2019 · 0 comments
Open

RPC doesn't start if blocks are not being generated #9

jholdstock opened this issue Apr 26, 2019 · 0 comments

Comments

@jholdstock
Copy link
Member

Testnet had not seen a block for 5+ hours, and it caused some odd behaviour.

After unlocking the wallet, dcrlnd stopped listening on port 10009 and performed it's startup activities. It then logged the following:

2019-04-26 11:49:13.040 [INF] DCRW: Blockchain sync completed, wallet ready for general usage.

It seems like everything is ready, and at this point I would expect the RPC to be available on port 10009. However there is nothing listening on the port, and any usage of dcrlncli results in connection errors.

After speaking with @matheusd it seems that this is because dcrlnd only starts the RPC server after the wallet considers itself synced, and it won't consider itself synced if it hasn't seen a block for 2 hours. We should alter the logging so that instead of incorrectly saying the wallet is ready for usage, we inform the user that the wallet is not synced and thus the RPC is not available.

(Running commit 22a6961)

matheusd pushed a commit that referenced this issue Oct 16, 2019
…#10

In this commit, we fix an issue that was recently introduced as a result
of migration #10. The new TLV format ended up modifying the
serialization functions called in `serializePaymentAttemptInfo`.
Migration #9, also used this `serializePaymentAttemptInfo` method to
serialize the _new_ (pre TLV, but new payment attempt structure) routes
into the database during its migration. However, migration #10 failed to
copy over the existing unmodified `serializePaymentAttemptInfo` method
into the legacy serialization for migration #9. As a result, once
migration #9 was run, the routes/payments were serialized using the
_new_ format, rather than the format used for v0.7.1. This then lead to
de-serialization either failing, or causing partial payment corruption
as migration #10 was expecting the "legacy" format (no TLV info).

We fix this issue by adding a new fully enclosed
`serializePaymentAttemptInfoMigration9`method that will be used for
migration #9. Note that our tests didn't catch this, as they test the
migration in isolation, rather than in series which is how users will
encounter the migrations.

Fixes lightningnetwork#3463.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant