salt: salt-ssh swallows exceptions in custom modules

Description of Issue/Question

Setup

salt:/srv # cat salt/_modules/foo.py
def bar():
    raise Exception()


salt:/srv # cat salt/t.sls
{% if salt['foo.bar']() %}
  errTrue
{% else %}
  errFalse
{% endif %}



salt:/srv # salt-ssh foohost state.sls t
foohost:
    - SLS t does not render to a dictionary
    - Error when rendering state with contents: errTrue



salt-ssh --log-level=all foohost state.sls t 2> tmp/o

relevant part of tmp/o

Traceback (most recent call last):
  File "/var/tmp/.root_dcdf8c_salt/salt-call", line 15, in <module>
    salt_call()
  File "/var/tmp/.root_dcdf8c_salt/py2/salt/scripts.py", line 400, in salt_call
    client.run()
  File "/var/tmp/.root_dcdf8c_salt/py2/salt/cli/call.py", line 57, in run
    caller.run()
  File "/var/tmp/.root_dcdf8c_salt/py2/salt/cli/caller.py", line 134, in run
    ret = self.call()
  File "/var/tmp/.root_dcdf8c_salt/py2/salt/cli/caller.py", line 212, in call
    ret['return'] = func(*args, **kwargs)
  File "/var/tmp/.root_dcdf8c_salt/running_data/var/cache/salt/minion/extmods/modules/foo.py", line 2, in bar
    raise Exception()
Exception

You see: an exception in the custom module does silently get a boolean True.

At least on my system: salt 2018.3.2 (Oxygen)

Versions Report

salt:/srv # salt --versions-report
Salt Version:
           Salt: 2018.3.4
 
Dependency Versions:
           cffi: 1.1.0
       cherrypy: 3.6.0
       dateutil: 2.1
      docker-py: Not Installed
          gitdb: 0.6.4
      gitpython: 1.0.1
          ioflo: Not Installed
         Jinja2: 2.10
        libgit2: 0.22.0
        libnacl: Not Installed
       M2Crypto: 0.22
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.6.1
   mysql-python: Not Installed
      pycparser: 2.12
       pycrypto: 2.6.1
   pycryptodome: Not Installed
         pygit2: 0.22.0
         Python: 2.7.3 (default, Apr 14 2012, 08:58:41) [GCC]
   python-gnupg: Not Installed
         PyYAML: 3.13
          PyZMQ: 17.1.2
           RAET: Not Installed
          smmap: 0.9.0
        timelib: Not Installed
        Tornado: 4.5.3
            ZMQ: 4.2.5
 
System Versions:
           dist: SuSE 12.3 x86_64
         locale: UTF-8
        machine: x86_64
        release: 4.4.114-42.1-default
         system: Linux
        version: openSUSE  12.3 x86_64

Related discussion on the user mailing list: https://groups.google.com/forum/#!topic/salt-users/jbtZ5T92xCY

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 16 (14 by maintainers)

Commits related to this issue

Add tests for issues #64531 and #52452 — committed to lkubb/salt by lkubb a year ago
Add tests for issues #64531 and #52452 — committed to lkubb/salt by lkubb a year ago
Add tests for issues #64531 and #52452 — committed to lkubb/salt by lkubb a year ago
Add tests for issues #64531 and #52452 — committed to lkubb/salt by lkubb a year ago
Add tests for issues #64531 and #52452 — committed to saltstack/salt by lkubb a year ago

Most upvoted comments

Today I came across this swallowing of exceptions again. But I am deeply relaxed. I will switch my job in one week, and then I don’t need to work with salt any more. I am relieved. Ansible is coming.

guettli on Dec 12, 2019

Someone may be able to correct me, but I’m not sure that’s what modules are for.

Modules are typically executed either like:

salt foohost foo.bar

Or, using states:

do some foo:
  module.run:
    - name: foo.bar

Just for some further information, could you try using the test state like so:

{% if salt['foo.bar']() %}
truthy:
  test.fail_without_changes:
    - name: should_not_be_here
{% else %}
falsey:
  test.nop:
    - comment: Okay, that call was false
{% endif %}

You might also try:

test things:
  test.nop:
    - comment: {{ salt['foo.bar']() }}

HTH!

waynew on Apr 9, 2019