Bug 1641266

Summary:	Wrong counts of success/fail/pending tasks on Bulk actions
Product:	Red Hat Satellite	Reporter:	Pavel Moravec <pmoravec>
Component:	Tasks Plugin	Assignee:	Adam Ruzicka <aruzicka>
Status:	CLOSED ERRATA	QA Contact:	tstrych
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6.4	CC:	aruzicka, ehelms, inecas, jhutar, ktordeur, mmccune, tstrych
Target Milestone:	6.5.0	Keywords:	PrioBumpField, Triaged
Target Release:	Unused
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	tfm-rubygem-dynflow-1.1.5,tfm-rubygem-foreman-tasks-0.14.4	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-05-14 12:38:16 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Pavel Moravec 2018-10-20 17:50:05 UTC

Description of problem:
(this was first seen in 6.3.4 but reproduced on 6.4 as well)

Running a bulk action, I get very contradicting stats about overall # tasks, successful/fail/pending/..

E.g. when I run auto-attach against 5 systems where two of them were deleted meantime, I see:
- parent task shows "5 task(s), 3 success, 4 fail"
- sub tasks show 4 success and 4 fail
- dynflow console of the parent task shows:
planned_count: 4
cancelled_count: 0
total_count: 5
failed_count: 4
pending_count: 1
success_count: 3

The failed tasks are two per each of 2 deleted system. Pending count might be consequence of that disbalance, but I already saw 10k total count, 0 failed, 9900 success and 100 pending (while there was _no_ pending, really).


Version-Release number of selected component (if applicable):
Sat 6.4


How reproducible:
100%


Steps to Reproduce:
(I expect the problem is more generic but providing a particular reproducer I noticed at customer and by myself)
1. Have 5 Content Hosts
2. In WebUI, click to Content Hosts -> select all 5 of them -> Select Action -> Manage Subscriptions
3. Exactly now, unregister 2 from the Content Hosts
4. Now click to Auto-Attach button to trigger the bulk task.
5. wait till the task completes
6. check all possible stats about the bulk action


Actual results:
6. see Description


Expected results:
6. stats to match reality and be aligned to each other


Additional info:

Comment 1 Adam Ruzicka 2018-10-23 10:02:58 UTC

Created redmine issue http://projects.theforeman.org/issues/25282 from this bug

Comment 2 Adam Ruzicka 2018-10-23 10:05:45 UTC

I didn't try to reproduce this, but I can see how this might be happening.

Comment 4 Satellite Program 2018-10-23 12:07:52 UTC

Upstream bug assigned to aruzicka

Comment 5 Satellite Program 2018-10-23 12:07:55 UTC

Upstream bug assigned to aruzicka

Comment 8 Satellite Program 2018-12-07 15:08:22 UTC

Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/25282 has been resolved.

Comment 12 tstrych 2019-03-21 17:34:44 UTC

Hi, 
Steps were reproduced with 5 content hosts. Exactly same result as in comment #1. 
To be able register content hosts manifest and activation key were created. 
Content host machines were pure 7.6 RHEL.

Using Satellite 6.4.2. 
- package versions:
  tfm-rubygem-dynflow-1.0.5.5-1
  tfm-rubygem-foreman-tasks-0.13.4.3-1

Steps were also reproduced on sat6.5 snap 20.
- package versions:
  tfm-rubygem-dynflow-1.1.6-1
  tfm-rubygem-foreman-tasks-0.14.4.4-2

Results with 5 content hosts on sat 6.5:
- parent task shows "5 task(s), 3 success, 2 fail" ... OK
- sub tasks shows "5 task(s), 3 success, 2 fail" ... OK
- raw output (last tab): 
  {"planned_count"=>5,
   "cancelled_count"=>0,
   "total_count"=>5,
   "failed_count"=>2,
   "pending_count"=>0,
   "success_count"=>3} ... OK 

In this case everything works as I expect. 

Verified.

Comment 14 Pavel Moravec 2019-04-04 13:03:17 UTC

Alternative reproducer (also for testing):

- have 2 Capsules assigned to Dev Lifecycle environment
- switch down one Capsule
- promote some CV to Dev LE
- that will trigger a BulkAction task to sync the new content to Capsules
- this task has _three_ sub plans / three individual CapsuleSync tasks will be triggered - two of them for the shutdown Capsule

Comment 18 errata-xmlrpc 2019-05-14 12:38:16 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2019:1222