You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
Recovered wallet with 30 BAT
set AC amount to Up to 20 BAT
add verified and non verified publishers to AC table
add verified recurring tips in this order (5, 10, 10, 10, 1)
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.
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.
The text was updated successfully, but these errors were encountered:
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: