Bug 1376650

Summary: downgrade to 23 fails if commands have been run: duplicate primary key inserting into activity
Product: [Retired] Beaker Reporter: Dan Callaghan <dcallagh>
Component: generalAssignee: Dan Callaghan <dcallagh>
Status: CLOSED CURRENTRELEASE QA Contact: tools-bugs <tools-bugs>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: developCC: dcallagh, dowang, mjia, rjoost
Target Milestone: 24.0Keywords: Patch, Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-02-21 18:50:31 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:

Description Dan Callaghan 2016-09-16 04:53:16 UTC
Description of problem:


Version-Release number of selected component (if applicable):
unreleased develop 3106040988c939637c8fbcb6a74b45c17ce145ea

How reproducible:
yes.

Steps to Reproduce:
1. beaker-init --downgrade 23

Actual results:
Downgrade crashes:
[...]
  File "Server/bkr/server/alembic/versions/3028e6a6e3d7_separate_command_queue_from_activity.py", line 69, in downgrade
[...]
sqlalchemy.exc.IntegrityError: (IntegrityError) (1062, "Duplicate entry '39988438' for key 'PRIMARY'") "\n        INSERT INTO activity (id, user_id, created, type, field_name, service,\n            action, old_value, new_value)\n        SELECT id, user_id, queue_time, 'command_activity', 'Command', service,\n            action, '', SUBSTRING(error_message, 1, 60)\n        FROM command_queue\n        " ()


Expected results:
Downgrade succeeds.

Additional info:
The problem is that the downgrade script is expecting that every row in the command_queue table originally had a matching row in activity (which it did, prior to the patch for separating command queue from activity). So if you downgrade immediately after you upgraded, that assumption still holds, and the matching activity rows are correctly restored (this is what happens in the test suite).

However if you upgrade and then run Beaker for a while, producing *new* rows in the command_queue table, those new rows will be assigned incrementing ids which are now conflicting with the ids in the activity table. It is no longer valid to just insert the same ids into activity on downgrade.

Comment 1 Dan Callaghan 2016-09-19 02:28:40 UTC
http://gerrit.beaker-project.org/5238

Comment 2 Dan Callaghan 2016-09-30 00:59:11 UTC
This bug fix is included in beaker-server-24.0-0.git.110.b8b172a.el6eng which is currently available for download here:

https://beaker-project.org/nightlies/develop/

Comment 4 Dan Callaghan 2017-02-21 18:50:31 UTC
Beaker 24.0 has been released.