file.managed always redownloads the file

[cetra3]

Description of Issue/Question

We have a few file.managed states of which some files fit in the cache, and some don't. It appears that in newer versions (2017.7.1) it will always download the file from HTTP if it doesn't live in the salt cache.

The checksum of the file is the same as the one on the remote server, and I can see it getting the checksum from the source_hash parameter, but I can also see it trying to download the file.

Was working fine before upgrade, so appears to be a regression.

Setup

Assuming file.zip is bigger than the salt cache parameters:

/path/to/local/file.zip:
  file.managed:
    - source: http://some.website/file.zip
    - source_hash: http://some.website/file.zip.md5

Where file.zip.md5 is simply a plain text representation of the md5 hash, i.e:

68b329da9893e34099c7d8ad5cb9c940

Steps to Reproduce Issue

Run salt '*' state.sls thestate

Versions Report

Salt Version:
           Salt: 2017.7.1
 
Dependency Versions:
           cffi: Not Installed
       cherrypy: Not Installed
       dateutil: 1.5
      docker-py: Not Installed
          gitdb: Not Installed
      gitpython: Not Installed
          ioflo: Not Installed
         Jinja2: 2.7.2
        libgit2: Not Installed
        libnacl: Not Installed
       M2Crypto: Not Installed
           Mako: 0.9.1
   msgpack-pure: Not Installed
 msgpack-python: 0.4.6
   mysql-python: 1.2.3
      pycparser: Not Installed
       pycrypto: 2.6.1
   pycryptodome: Not Installed
         pygit2: Not Installed
         Python: 2.7.6 (default, Oct 26 2016, 20:30:19)
   python-gnupg: Not Installed
         PyYAML: 3.10
          PyZMQ: 14.0.1
           RAET: Not Installed
          smmap: Not Installed
        timelib: Not Installed
        Tornado: 4.2.1
            ZMQ: 4.0.5
 
System Versions:
           dist: Ubuntu 14.04 trusty
         locale: ANSI_X3.4-1968
        machine: x86_64
        release: 3.19.0-69-generic
         system: Linux
        version: Ubuntu 14.04 trusty

[gtmanfred]

This is a duplicate of #42681 (comment)

Thanks,
Daniel

[terminalmage]

#43518 has been opened to fix this.