Bug 1339536 - ChildCommandsCallbackBase: getSucceeded() will return wrong persisted value
Summary: ChildCommandsCallbackBase: getSucceeded() will return wrong persisted value
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Storage
Version: 4.0.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ovirt-4.0.0-rc
: 4.0.0
Assignee: Liron Aravot
QA Contact: Aharon Canan
Depends On: 1226561
Blocks: 952703 1236075
TreeView+ depends on / blocked
Reported: 2016-05-25 09:35 UTC by Liron Aravot
Modified: 2016-08-01 12:26 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1226561
Last Closed: 2016-08-01 12:26:38 UTC
oVirt Team: Storage
rule-engine: ovirt-4.0.0+
rule-engine: planning_ack+
rule-engine: devel_ack+
acanan: testing_ack+

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
oVirt gerrit 58020 0 ovirt-engine-4.0 MERGED core: ChildCommandsCallbackBase - setSucceeded(false) 2016-05-25 10:33:49 UTC

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:

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.

Note You need to log in before you can comment on or make changes to this bug.