-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Comments
NejcZdovc
added
the
priority/P5
Not scheduled. Don't anticipate work on this any time soon.
label
Nov 18, 2019
closing as this is not relevant. Anonize was removed as part of #7595 |
NejcZdovc
added
closed/not-actionable
and removed
priority/P5
Not scheduled. Don't anticipate work on this any time soon.
labels
Apr 10, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
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 byPhaseTwo::VoteBatchCallback
for a successful response. ThestatusCode
anderror
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.
The text was updated successfully, but these errors were encountered: