Registration requests during Privet testing causes significant network traffic

[tblossfeld]

While testing the Privet suite of tests in the newapi GCP certification tool, I discovered that our virtual printer will spam a series of FETCH requests until the registration is either accepted, cancelled, or times out. This does not occur during a manual registration attempt from the same system/gmail account. It seems likely to be caused by something specific to how the registration requests are being handled within the Privet test suite.

You can see a snippet of the text here:

[chok]

Could you please provide the test case that you are seeing this from?

Indeed in the test script, there are sections where the user is expected to manually accept/cancel the registration over the printer's UI. The script intelligently waits for this interaction by repeatedly calling the /privet/register?action=getClaimToken API until it returns success (with a 1 second wait between calls). As long as getClaimToken is returning the benign error, 'pending_user_action', the script will continue to call the API until it succeeds.

[tblossfeld]

Thanks for the reply. I was able to narrow it down to the following specific tests:

Privet
testDeviceRegistrationInvalidClaimToken
testDeviceRegistrationInvalidUserAuthToken
PreRegistration
testDeviceCancelRegistration
testDeviceRegistrationNotLoggedIn

[chok]

Each of these test cases require manual interaction to confirm or cancel a registration request. Each of the test cases listed prompts the user to either accept or deny a registration request on the printer's UI.

In the case of your virtual printer, is there some way for you to do this?

[tblossfeld]

Yes, we are able to accept or cancel registration with the virtual printer. However, the message requesting the user to do so gets lost in the series of messages that occurs during these tests. Once I have accepted or cancelled, the issue stops. It should be noted, however that similar tests do not show this issue, such as "testDeviceRegistrationNoAccept". In the case of this test, there is some repeated FETCH request messages, but it is much slower and allows the tester to see the request to either accept or cancel the registration. Of course, the tester isn't supposed to do anything in this case until the registration attempt has timed out, but it does suggest that the cert tool could be handling getClaimToken differently for this case.

[chok]

For "testDeviceRegistrationNoAccept", it only calls the start() Privet API and never calls getClaimToken(). Which explains why you are not getting flooded with FETCH requests.

Perhaps there is a way to mute the FETCH messages from the output so that the cert tool's instructions are not getting drowned out.

[Michael Rhines]

I believe that the 1 second wait in logocert_api/_device.py GetPrivetClaimToken is not working as intended.

I think the newline at line 284 terminates the while loop which is therefore spinning tightly causing the reported symptom.

[chok]

Hi Michael,

I have fixed a loop-control bug which caused the polling sleep to be skipped when user interaction is expected. It was due to the continue keyword being used without sleeping beforehand. My apologies!

Please pull from the logocert_api branch again and let me know if the spamming issue persists.

Thanks,
Kevin

[Michael Rhines]

Hi Kevin.
Our QA team will pull this commit and verify the fix.
Thanks!

• Mike Rhines

[tblossfeld]

Thanks, Kevin. I've downloaded the latest and tested this issue. It has been resolved.

Thanks,
Tom