Project

General

Profile

Actions

Bug #4898

closed

WorkflowRun entityId lsid no longer incrementing after getting tagged

Added by Derik Barseghian almost 15 years ago. Updated over 14 years ago.

Status:
Resolved
Priority:
Normal
Category:
workflow run manager
Target version:
Start date:
03/19/2010
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
4898

Description

Looks like after the refactor the WorkflowRun entityId lsid revision no longer gets bumped when a run gets tagged.

To replicate:
Run a workflow
Export the run
Tag the run
Export the run to another kar
Compare the two serialized runs' entityIds (or just look use the view lsid gui)

A second problem is that the tagged version gets a derivedFrom lsid. And this lsid seems to be new...which doesn't make sense. Was this lsid intended to go into the entityId? Even if that worked, I think it makes more sense to just increment the revision for tag events. This is what happens for workflows.


Related issues

Blocked by Kepler - Bug #4895: Exporting multiple runs gives duplicate entry errorsResolvedDerik Barseghian03/19/2010

Actions
Actions #1

Updated by Derik Barseghian almost 15 years ago

Also of note, if you restart Kepler and then use the View Run LSID context menu on such a tagged run, the derivedLSID no longer shows.

Actions #2

Updated by Derik Barseghian over 14 years ago

I'm going to look at this.
On a related note, I've discussed making changes to the system so that provenance's workflow_exec lsid's revision is incremented when changes to the run in the WRM are made (i.e. tags).

Actions #3

Updated by Derik Barseghian over 14 years ago

The first problem should be fixed in r23532.
The second problem where WorkflowRuns are getting derivedFrom lsids is still a bug.

Actions #4

Updated by Derik Barseghian over 14 years ago

second part fixed in r23536

Actions #5

Updated by Redmine Admin over 11 years ago

Original Bugzilla ID was 4898

Actions

Also available in: Atom PDF