Currently most browsers either stream PDF content to display themselves or for products like Adobe Reader you can often add an extension to open stream with … (that route in the past was done by a now depreciated SumartraPDF Netscape plugin)
The current alternative is to download the PDF and use double click to open in system default PDF viewer or right click for a context start-up (I use multiple SendTo)
Within my ungoggled Chrome if I change settings to not display it internally, then it downloads to a link on bottom bar that I can use to Open OR set to Always open with default. So I have to ask is that the way yours is set ?
There have not been masses of users complaining of problems with Chrome downloads so have to presume something is different within your usage.
From your description, it sounds like SumatraPDF is triggered too quickly in a system with some interfering delay. (Anti-Virus?) after a download, but if there is some chrome extension also at play that may need to also be considered.
Personally I either view in or fully download via ChromEdgium, thus wait for intrusive “the file never had a virus anyway” but is going to exclusively block access, till it tells nanny at MS towers what I am reading, Then open the now second hand duplicated stored file.
With old browser plug-in that was much simpler and less secure, (still could have problems) as it opened the remote unvetted file often before it was fully mirrored locally.
However the only browsers that still allows such legacy SumatraPDF plugin behaviour are Waterfox Classic and Pale Moon, and those eventually will retire such fast usage.
Back to the problem:
I doubt, should it be there is a delayed access, that a newer version would make any difference, but SumatraPDF fixes can only be made against latest DailyBuilds
If I am right the solution may be to add a “retry delay variable” before passing the filename into SumatraPDF rendering such as to avoid your workaround method.