[BUG] salt.states.sync_all does not always work

Description For some reason salt.states.sync_all doesn’t work consistently. I first had the problem because I was originally using module.run with the old deprecated syntax. I switched over to the new syntax for module.run, and then discovered that you guys implemented it as a state.

Setup There’s two environments. One of them is named “base”, the other is named “bootstrap”. The minion is using “bootstrap” and “base” is actually never used. The minion is running the 3000.3 py3 installer.

Steps to Reproduce the behavior This is literally copied and pasted straight out of my terminal.

master salt # salt $m test.ping
jid: 20200612103924174230
HUVp16SeYiPt2L50peVt:
    True


-------------------------------------------
Summary
-------------------------------------------
# of minions targeted: 1
# of minions returned: 1
# of minions that did not return: 0
# of minions with errors: 0
-------------------------------------------
master salt # cat > wtf.sls
wtf:
 saltutil.sync_all:
  - saltenv: bootstrap
master salt # salt $m state.apply wtf
jid: 20200612104023702610
HUVp16SeYiPt2L50peVt:
  Name: wtf - Function: saltutil.sync_all - Result: Clean Started: - 11:40:24.452815 Duration: 1246.684 ms

Summary for HUVp16SeYiPt2L50peVt
------------
Succeeded: 1
Failed:    0
------------
Total states run:     1
Total run time:   1.247 s


-------------------------------------------
Summary
-------------------------------------------
# of minions targeted: 1
# of minions returned: 1
# of minions that did not return: 0
# of minions with errors: 0
-------------------------------------------
master salt # salt $m saltutil.sync_all saltenv=bootstrap
jid: 20200612104135151899
HUVp16SeYiPt2L50peVt:
    ----------
    beacons:
    clouds:
    engines:
    executors:
    grains:
    log_handlers:
    matchers:
    modules:
        - modules.chocolatey
        - modules.win_system
    output:
    proxymodules:
    renderers:
    returners:
        - returners.etcd_return
    sdb:
    serializers:
    states:
        - states.git
        - states.win_system
    thorium:
    utils:
        - utils.network
        - utils.win_reg


-------------------------------------------
Summary
-------------------------------------------
# of minions targeted: 1
# of minions returned: 1
# of minions that did not return: 0
# of minions with errors: 0
-------------------------------------------

Expected behavior I’m trying to use this to sync modules that contain bugfixes for things that are broken. I expect this to sync modules into the minion. It unfortunately does not.

Screenshots

Versions Report Salt Version: Salt: 3000.3

Dependency Versions: cffi: 1.12.2 cherrypy: 17.4.1 dateutil: 2.8.0 docker-py: Not Installed gitdb: 2.0.5 gitpython: Not Installed Jinja2: 2.10.1 libgit2: Not Installed M2Crypto: Not Installed Mako: 1.0.7 msgpack-pure: Not Installed msgpack-python: 0.5.6 mysql-python: Not Installed pycparser: 2.19 pycrypto: Not Installed pycryptodome: 3.8.1 pygit2: Not Installed Python: 3.5.4 (v3.5.4:3f56838, Aug 8 2017, 02:07:06) [MSC v.1900 32 bi t (Intel)] python-gnupg: 0.4.4 PyYAML: 5.1.2 PyZMQ: 18.0.1 smmap: 2.0.5 timelib: 0.2.4 Tornado: 4.5.3 ZMQ: 4.3.1

System Versions: dist: locale: cp1252 machine: x86 release: 8.1 system: Windows version: 8.1 6.3.9600 SP0 Multiprocessor Free

[sagetherage]

@arizvisa can we please keep the issue title with Bug instead of alluding to profanity, please?

[arizvisa]

After upgrading to 3001, this issue doesn’t reproduce anymore similar to another issue that I submitted for 3000.3. I downgraded to 3000.3 to confirm my sanity and was still able to reproduce this one as well.

However, I’m closing this as it was fixed by some commit in-between 3000.3 and 3001 and that’s really all I care about. It gets progressively harder and harder to defend usage of this software when its maintenance requires you to be a Python developer.