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

need to handle getticketsvotebits errors better #15

Closed
jolan opened this issue Apr 21, 2016 · 5 comments
Closed

need to handle getticketsvotebits errors better #15

jolan opened this issue Apr 21, 2016 · 5 comments
Assignees
Labels
Milestone

Comments

@jolan
Copy link
Contributor

jolan commented Apr 21, 2016

votebits errors out when ticket doesn't exist due to mempool differences or when a missed/revoked ticket is present or not.

@mverrilli
Copy link
Contributor

This isn't only for missed and revoked tickets right? Or is this a separate issue?

I assume this is where the ticket list comes from? Could we union the responses from the different wallets since mempool could literally be any subset of the overall mempool? (Seems like there is still always a chance that some tickets may not be in the list when they are still in the mempool).

Or am I way off?

@jolan
Copy link
Contributor Author

jolan commented Apr 21, 2016

I was just listing some examples of de-synchronization from past issues and the goal would be to have the code work in a way where the inconsistency isn't a problem.

Can run ticketsforaddress and getticketsvotebits against each server individually.

Or just have getticketsvotebits ignore passing of an invalid ticket and work with a single response, they will eventually be consistent but then users may complain about missing tickets.

@jolan
Copy link
Contributor Author

jolan commented Nov 4, 2016

Bumping milestone to 0.7.0. PR #32 handles this but it needs more testing and it depends on the new setticketsvotebits functionality in 0.6.0. So once 0.6.0 is released, we can test/merge #32 and require 0.6.0.

@chappjc
Copy link
Member

chappjc commented Nov 4, 2016

I won't be offended if PR #32 goes to the scrap heap. There's no extended bits handling, and it's complex.

@jolan
Copy link
Contributor Author

jolan commented Nov 11, 2016

The situation was vastly improved by #60 so I don't see a reason to keep this open.

@jolan jolan closed this as completed Nov 11, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants