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
So the current code doesn't properly reset mProviderRetryCount after a successful download but image is not applied. Given that we now have two retry counters and they are incremented in different locations, we could be incrementing mProviderRetryCount even on an invalid session error:
Requestor successfully sends QueryImage (CASE established and mProviderRetryCount incremented to 1)
Provider is restarted
Requestor sends QueryImage -> invalid session detected -> CASE torn down
mInvalidSessionRetryCount incremented to 1 in HandleIdleStateEnter
mProviderRetryCount incremented to 2 in SendQueryImage
Given the current example app, after (5), we could get a successful query/download but never applied the image. The next time we attempt to query (and if it were busy), mProviderRetryCount already started at 2 instead of 0 and it would at most retry one more time.
Proposed Solution
Increment and reset mProviderRetryCount properly to reflect actual provider retry attempts.
The text was updated successfully, but these errors were encountered:
Problem
So the current code doesn't properly reset
mProviderRetryCount
after a successful download but image is not applied. Given that we now have two retry counters and they are incremented in different locations, we could be incrementingmProviderRetryCount
even on an invalid session error:mProviderRetryCount
incremented to 1)mInvalidSessionRetryCount
incremented to 1 inHandleIdleStateEnter
mProviderRetryCount
incremented to 2 inSendQueryImage
Given the current example app, after (5), we could get a successful query/download but never applied the image. The next time we attempt to query (and if it were busy),
mProviderRetryCount
already started at 2 instead of 0 and it would at most retry one more time.Proposed Solution
Increment and reset
mProviderRetryCount
properly to reflect actual provider retry attempts.The text was updated successfully, but these errors were encountered: