GothenburgBitFactory / bugwarrior

Pull github, bitbucket, and trac issues into taskwarrior
http://pypi.python.org/pypi/bugwarrior
GNU General Public License v3.0
734 stars 209 forks source link

bugwarrior-download does not exit on error #821

Closed fmauch closed 3 years ago

fmauch commented 3 years ago

OS: Arch Linux bugwarrior: develop branch (382ec44)

I have one bug source behind a private network, that I usually connect through vpn.

However, if my vpn connection is not running and bugwarrior-pull is running, it throws an error that the respective source cannot be reached:

ERROR:bugwarrior.services:Worker for [my_gitlab] failed: HTTPSConnectionPool(host='gitlab.example.com', port=443): Max retries exceeded with url: /api/v4/projects/helpdesk%2Fgitlab_helpdesk?simple=true (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7f162eb21a30>: Failed to establish a new connection: [Errno -2] Name or service not known'))
Traceback (most recent call last):
  File "/usr/lib/python3.9/site-packages/urllib3/connection.py", line 169, in _new_conn
    conn = connection.create_connection(
  File "/usr/lib/python3.9/site-packages/urllib3/util/connection.py", line 73, in create_connection
    for res in socket.getaddrinfo(host, port, family, socket.SOCK_STREAM):
  File "/usr/lib/python3.9/socket.py", line 953, in getaddrinfo
    for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno -2] Name or service not known

Further down I get

ERROR:bugwarrior.services:Aborted (critical error in target 'my_gitlab')
NoneType: None

Which all is absolutely fine. However, after that bw continues handling all tasks and closes all tasks related to the my_gitlab source.

I'd very much love to tackle this, but first I wanted to make sure that this is not a configuration error on my side. Am I missing something that I should add to my configuration in such a case?

ryneeverett commented 3 years ago

This is likely a regression I introduced in #801. If we can confirm it should be reverted.

ryneeverett commented 3 years ago

Thanks for the report and sorry for the inconvenience. I'm pretty sure #801 was indeed the issue and it's been reverted.

fmauch commented 3 years ago

Hi there,

sorry for not answering earlier, what a busy week...

Yes, indeed with #801 reverted I get

ERROR:bugwarrior.command:Aborted (critical error in target 'my_gitlab')
Traceback (most recent call last):
  File "${HOME}/local_install/src/bugwarrior/bugwarrior/command.py", line 73, in pull
    synchronize(issue_generator, config, main_section, dry_run)
  File "${HOME}/local_install/src/bugwarrior/bugwarrior/db.py", line 368, in synchronize
    for issue in issue_generator:
  File "${HOME}/local_install/src/bugwarrior/bugwarrior/services/__init__.py", line 572, in aggregate_issues
    raise RuntimeError(
RuntimeError: critical error in target 'my_gitlab'

This seems much more what I would expect in such a situation.

However, I guess that a) the error output could be somehow improved and b) other sources could indeed be updated. I guess, this setup is kind of special, where only once source out of multiple might not be reachable due to private networks, though.

ryneeverett commented 3 years ago

However, I guess that a) the error output could be somehow improved and b) other sources could indeed be updated. I guess, this setup is kind of special, where only once source out of multiple might not be reachable due to private networks, though.

825 should address all these concerns. While a private network configuration issues may be an unusual cause, my experience has been that it's quite common for a single service to be down and that is the scenario motivating this change.