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
Some time ago we ran into the issue that our application (containing some hundred megabytes of libraries) got a verification timeout since one client deployed it on a slow network device. We worked around this problem by increasing the verification timeout.
However, when analyzing the problem I discovered that in case of a verification timeout getdown does not mark the files that it could process until the timeout hit as verified. Hence, if a user runs the application again (maybe thinking: "some problem with a timeout, could be temporary, so I'll try again") verification will probably never succeed, as the same files are verified on each launch.
So, my suggestion would be, that in case of a verification timeout the fully verified files get marked accordingly and don't get re-verified when the application is launched again.
Of course the deployment of a large application on slow network devices is not advisable (and not suggested by us, but clients may have their own rationales and restrictions) and increasing the verification_timeout will probably work around it's consequences, so I the suggested optimization may be of lower priority or even a nice-to.
The text was updated successfully, but these errors were encountered:
Some time ago we ran into the issue that our application (containing some hundred megabytes of libraries) got a verification timeout since one client deployed it on a slow network device. We worked around this problem by increasing the verification timeout.
However, when analyzing the problem I discovered that in case of a verification timeout getdown does not mark the files that it could process until the timeout hit as verified. Hence, if a user runs the application again (maybe thinking: "some problem with a timeout, could be temporary, so I'll try again") verification will probably never succeed, as the same files are verified on each launch.
So, my suggestion would be, that in case of a verification timeout the fully verified files get marked accordingly and don't get re-verified when the application is launched again.
Of course the deployment of a large application on slow network devices is not advisable (and not suggested by us, but clients may have their own rationales and restrictions) and increasing the verification_timeout will probably work around it's consequences, so I the suggested optimization may be of lower priority or even a nice-to.
The text was updated successfully, but these errors were encountered: