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

Anonize votes rejected by server are treated by the client as successful #6775

Closed
jhoneycutt opened this issue Nov 5, 2019 · 1 comment
Closed

Comments

@jhoneycutt
Copy link

Description

After submitting a vote batch and receiving the result from the server, individual votes that failed are treated as successful by the client.

Found while investigating #6545.

Steps to Reproduce

I have only triggered this state by changing the client code to send duplicate votes, but I believe that this state can (infrequently) be reached by following these steps from #6607:

  1. enable rewards with short contribution interval on staging. Launched with --enable-logging=stderr --vmodule=rewards=6 --rewards=staging=true,reconcile-interval=10,short-retries=true to see log messages, use staging env, set short contribution interval, and short retry interval.
  2. Recovered wallet with 30 BAT
  3. set AC amount to Up to 20 BAT
  4. add verified and non verified publishers to AC table
  5. add verified recurring tips in this order (5, 10, 10, 10, 1)
  6. wait for monthly contribution to trigger

Actual result:

When the client receives failure responses related to the duplicate votes, those failures are treated as successful, and the client removes the votes from its outgoing queue.

Reproduces how often:

Bug #6607 that can result in duplicate votes is timing related and may be difficult to reproduce through normal usage. However, if the code is modified to generate duplicate votes, this bug always reproduces.

Brave version (brave://version info)

Brave 0.73.59 Chromium: 78.0.3904.87 (Developer Build) (64-bit)

Miscellaneous Information:

See this server response for a batch of duplicate votes:
duplicate votes response.txt

Note that the HTTP status code is successful, that it's valid JSON, and that the response is an array of objects, each with a surveyorId property. Thus it fulfills all of the checks made by PhaseTwo::VoteBatchCallback for a successful response. The statusCode and error properties of the objects are not checked. The votes are treated as successful and removed from the outgoing queue by the client.

I believe that this bug is why #6607 does not generate an infinite loop of failed vote retries.

@NejcZdovc NejcZdovc added the priority/P5 Not scheduled. Don't anticipate work on this any time soon. label Nov 18, 2019
@NejcZdovc
Copy link
Contributor

closing as this is not relevant. Anonize was removed as part of #7595

@NejcZdovc NejcZdovc added this to the Dupe / Invalid / Not actionable milestone Apr 10, 2020
@NejcZdovc NejcZdovc added closed/not-actionable and removed priority/P5 Not scheduled. Don't anticipate work on this any time soon. labels Apr 10, 2020
@bbondy bbondy removed this from the Dupe / Invalid / Not actionable milestone May 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants