Bug 1339536

Summary:	ChildCommandsCallbackBase: getSucceeded() will return wrong persisted value
Product:	[oVirt] ovirt-engine	Reporter:	Liron Aravot <laravot>
Component:	BLL.Storage	Assignee:	Liron Aravot <laravot>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Aharon Canan <acanan>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	4.0.0	CC:	acanan, ahadas, amureini, bugs, gklein, laravot, lpeer, lsurette, mperina, oourfali, pstehlik, rbalakri, Rhev-m-bugs, rnori, srevivo, tnisan, ykaul
Target Milestone:	ovirt-4.0.0-rc	Keywords:	CodeChange
Target Release:	4.0.0	Flags:	rule-engine: ovirt-4.0.0+ rule-engine: planning_ack+ rule-engine: devel_ack+ acanan: testing_ack+
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	1226561	Environment:
Last Closed:	2016-08-01 12:26:38 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Storage	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1226561
Bug Blocks:	952703, 1236075

Description Liron Aravot 2016-05-25 09:35:41 UTC

Description of problem:
In bz 1083769 the command return value was added to the persisted command entity.
when the command is rebuilt from the command entity, the persisted return value is loaded and set to it. The return value contains a flag to indicate on succesful indication, if that flag was set previously to true it'll contain wrong value.

How reproducible:
100%

Actual results:
when reaching the command endAction() (from the callback end methods) and failing getSucceeded() will return true instead of false.

Expected results:
the initial getSucceded() value before endAction() should be false.

Comment 1 Red Hat Bugzilla Rules Engine 2016-05-25 09:36:05 UTC

Bug tickets must have version flags set prior to targeting them to a release. Please ask maintainer to set the correct version flags and only then set the target milestone.

Comment 3 Carlos Mestre González 2016-07-11 12:27:49 UTC

Hi Liron, How are we suppose to test this?

Comment 4 Liron Aravot 2016-07-12 12:29:18 UTC

Hi Carlos,
As this issue is infra-ish and hard to reproduce i'm marking this as CodeChange and verified.
If it will ever occur we'll encounter it on the using flows.