application does not return non-zero code upon failure

[pcrespov]

Application run does return non-zero code upon failure.

Steps to reproduce

Running w/o arguments displays help and exit code 1

$ docker run hsorby/opencor-python
...
$ echo $?
1

Running w/ arguments runs through and returns exit code 0

$ docker run hsorby/opencor-python 1000.0
... [json result in stdout] ...
$ echo $?
0

Running w/ an invalid input runs though, reports error message in the std::err BUT still returns exit code 0

$ docker run hsorby/opencor-python 5
Traceback (most recent call last):
  File "run_model.py", line 39, in <module>
    main(period)
  File "run_model.py", line 21, in main
    s.run()
RuntimeError: std::runtime_error: at t = 7.89335, mxstep steps taken before reaching tout
$ echo $?
0

In this case, the expected behavior would be to get a non-zero. This way, the client can detect that something went wrong and e.g. show the user the std::err

Some insight

In order to understand better this, I built myself the image and tagged as opencor-python:dev, run the container and executed the command in the entrypoint.sh.

$ docker run -it --entrypoint /bin/bash opencor-python:dev

I noticed that i can reproduce the same in the executable

root@f801628872b5:/home/opencor# ./OpenCOR-2019-05-23-Linux/bin/OpenCOR -c PythonRunScript::script run_model.py 5
Traceback (most recent call last):
  File "run_model.py", line 39, in <module>
    main(period)
  File "run_model.py", line 21, in main
    s.run()
RuntimeError: std::runtime_error: at t = 7.89335, mxstep steps taken before reaching tout
root@f801628872b5:/home/opencor# echo $?
0

See that python interpreter, would return 1 if there is an exception raised:

root@f801628872b5:/home/opencor# OpenCOR-2019-05-23-Linux/python/bin/python -c "raise Exception"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
Exception
root@f801628872b5:/home/opencor# echo $?
1

[hsorby]

Running w/ arguments runs through and returns exit code 0

$ docker run hsorby/opencor-python 1000.0
... [json result in stdout] ...
$ echo $?
1

I take it that this should read:

$ echo $?
0

And that the 1 is a typo?

If that is the case it looks like this is an upstream issue and I will pass it on.

[hsorby]

On second look this might be me. I'll try and find a return code and pass it up.

[hsorby]

And it turns out when passing up a return code the OpenCOR Python module is causing a segmentation fault which is an upstream problem.

I'll pass this one on.

[pcrespov]

Running w/ arguments runs through and returns exit code 0

$ docker run hsorby/opencor-python 1000.0
... [json result in stdout] ...
$ echo $?
1

I take it that this should read:

$ echo $?
0

And that the 1 is a typo?

Running w/ arguments runs through and returns exit code 0

$ docker run hsorby/opencor-python 1000.0
... [json result in stdout] ...
$ echo $?
1

I take it that this should read:

$ echo $?
0

And that the 1 is a typo?

Yes, sorry, that was a typo :-) it returns 0

[hsorby]

Great, upstream issue is dbrnz/opencor#27

[hsorby]

Fixed in version 0.2.2 of the image.