When the checkbox to always check local content is enabled, it can be common for the hash not to match if the local content file hash doesn't match because it's older.
In this case, when the hash doesn't match rather than failing we should fall back and attempt to download the binary from the URL source (When it's not offline only product)
Here's an example of the scenario that could be improved:
Searching GoogleChromeStandaloneEnterprise64.msi in \\SCCM\Source Files\PatchMyPCRepository or one of its subfolders...
The local file is: \\SCCM\Source Files\PatchMyPCRepository\Applications\Google, Inc_\Google Chrome (x64)\153985b0-407e-49b5-ba09-deb948689b69\GoogleChromeStandaloneEnterprise64.msi
Successfully copied the update binary
The hash of file downloaded is different than the file hash in our catalog. Hash errors happen when vendors release updates that aren't available in our catalog yet. This error should be resolved in the next catalog update. Additional details: Downloaded Hash [6O99oqdffzsh/zHiZ7HtdoSz4EY=] Catalog Hash [qDviWTYjSuAxaOujGysRcqYy3ec=]
The update/app would then fail to publish. In a hash issue where a local content file is used, we should attempt to download from the internet to publish the content.