Don't terminate all services on failure. (attempt 2)

[ryneeverett]

Fix #279.

After reverting #801, this second attempt includes a fix and regression test for #821.

[fmauch]

I just tested this branch and while giving clean error output

ERROR:bugwarrior.services:Aborted my_gitlab due to critical error.

it starts completing all my tasks related to the my_gitlab source.

[ryneeverett]

Ugh, thanks again.

I hadn't noticed that the initial list of issues to close was built before issue aggregation at which point it was too late to change the services whose issues went into this list.

I implemented and pushed a new strategy.

[fmauch]

Nope, still the same behavior for me.

[ryneeverett]

Hmm, I don't get it. I force pushed a debug line to log the succeeding services which are the only ones whose issues should be subject to being closed. Could you re-pull and run with --debug?

[fmauch]

Hmm, I don't get it. I force pushed a debug line to log the succeeding services which are the only ones whose issues should be subject to being closed. Could you re-pull and run with --debug?

That output looks correct:

DEBUG:bugwarrior.db:Closing tasks for succeeding services: ['github_assigned', 'github_my_prs', 'github_reviews_requested'].

my_gitlab is not in the list.

However, I just realize (sorry, I didn't see this earlier), that now my tasks from github get completed:

DEBUG:bugwarrior.db:Skipping.  Seen {"githubtype": "pull_request", "githuburl": "https://github.com/UniversalRobots/Universal_Robots_ExternalControl_URCap/pull/19"} of <github_reviews_requested: (bw)PR#19 - Added a test, that verifies that th .. https://github.com/UniversalRobots/Universal_Robots_ExternalControl_URCap/pull/19>
INFO:bugwarrior.services:Done aggregating remote issues.
INFO:bugwarrior.db:Adding 0 tasks
INFO:bugwarrior.db:Updating 1 tasks
INFO:bugwarrior.db:Updating task 8f57e15c-f09f-4b44-a817-592a07fb32b8, (bw)PR#416 - Added "On behalf of Universal Robot .. https://github.com/UniversalRobots/Universal_Robots_ROS_Driver/pull/416; status: 'completed' -> 'pending'; end: datetime.datetime(2021, 6, 25, 7, 25, 43, tzinfo=tzutc()) -> None
DEBUG:bugwarrior.db:Closing tasks for succeeding services: ['ros_as_a_service', 'github_assigned', 'github_my_prs', 'github_reviews_requested'].
INFO:bugwarrior.db:Closing 20 tasks
INFO:bugwarrior.db:Completing task aabf2048-4fbe-42cc-a55e-b50e5a0590fd (bw)PR#6 - Use released binary versions of ups .. https://github.com/UniversalRobots/Universal_Robots_ROS_passthrough_controllers/pull/6
INFO:bugwarrior.db:Completing task aaff4e56-8072-450b-aad1-dfc9d9f88f0c (bw)Is#380 - Starting the Controllers after rele .. https://github.com/UniversalRobots/Universal_Robots_ROS_Driver/issues/380
INFO:bugwarrior.db:Completing task 4bae5d15-da67-4083-8b08-80df2bd5eef0 (bw)PR#26 - Improve primary interface .. https://github.com/UniversalRobots/Universal_Robots_Client_Library/pull/26

Maybe, there's something wrong with assigning the IDs?

[ryneeverett]

Does re-running bugwarrior re-open those closed issues? In other words, are you sure that they're pulled in by your service configuration?

The logic change to issue closing is simple and I'm not sure how I could have screwed it up this time. Before, we compiled a list of all the uuid's of tasks in taskwarrior managed by the bugwarrior services and deleted them as we looped through the issues pulled in. Now, we create a list of the uuid's pulled in as we loop through them and then close all bugwarrior-managed tasks that weren't seen. I guess I'm a bit rusty on sets but the - operator seems pretty straightforward...

[fmauch]

Yes, when going into my vpn network so that my_gitlab gets updated correctly, the github tasks get re-opened.

I'll try to understand and debug this a little myself...