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.
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.