this is mildly related to issue 619834, which is another way dangerous links were being surfaced to users

It appears to me that dangerous download item probably need to be removed instead of canceled in DownloadManagerImpl::Shutdown().... But, that part of code hasn't been changed for years. So, this is not the cause of this problem. 
asanka@, do you have any insights about what went wrong here?

The code for removal is there, but the problem is that it is being done at shutdown time where the resulting thread hops aren't reliable :-(

There are ways to implement this logic in a shutdown/crash friendly manner. E.g.: On Windows, we can create the intermediate quarantined file using DELETE_ON_CLOSE so that once all the file handles go away, the file will be deleted. If the user chooses to keep/recover the file, then Chrome can create a new hardlink to it instead of closing+renaming as is done now. This way the old link will be removed when the previous file handle is closed, and the new link will continue to point at the file.

This way, if Chrome crashes or performs an unclean shutdown, the intermediate file will always be cleaned up as expected.

We also need to rework how we handle the downloads database. It currently attempts to mirror the in-memory state, which isn't a good design. It should ideally represent what we want to see persisted if the browser were to crash right now. This assertion is viable for downloads (not true in general), and we should move in that direction. In addition to smoother recovery after a crash, this would also mean that we have less work to do during shutdown.

Not going to happen for M54.

asanka@, could you take on this one? 

Bulk assigning bugs with identified owners.

asanka@ -- any update on this P1? Do you think we should change the priority?

+dtrainor for re-triaging.

+qinmin@, do you have time to take a look at this one?

dtrainor@, could you help in finding a owner for this issue?  Thanks!

Sorry for the delay on this.  Assigning to xingliu@ to investigate over the next few weeks.  The larger history db refactor isn't something we can do in the short term, but Asanka's suggestions around handling this in other ways sounds reasonable.