Project

General

Profile

Bug #4228

Not all tokens seem to be written when running WF from commandline

Added by ben leinfelder about 10 years ago. Updated about 10 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
provenance
Target version:
Start date:
07/08/2009
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
4228

Description

I'm still trying to isolate the problem, but I'm finding that a RecordToken is not "fully" being written to provenance.
When I run in the GUI I see that the token has two port_event rows: one with a write_event_id=-1 and another with a write_event_id that corresponds to the previous row.
When running from the commandline I only see the write_event_id = -1 row and nothing else.

The recordToken is being passed to a display actor - perhaps the non-GUI filter is removing that connection and the port firing is modified? That's my only lead so far...

I will try to make a simpler workflow to isolate it.


Related issues

Blocked by Kepler - Bug #4197: Waterflow TPC demo - tracking bugResolved06/29/2009

History

#1 Updated by Christopher Brooks about 10 years ago

If you can figure out how to call exportMoML() on the top level, then
you can get the moml after the filter is run. It could be that
the problem is that the input port of the Discard is not a multiport
and that the Display is being replaced with a Discard?

#2 Updated by ben leinfelder about 10 years ago

tracked down one issue - was looking up token type/value based on the read row in provenance even though we were interested only in the write (token on the output port).

Still encountering a different workflow-specific problem for the base TPC - might be related. keeping bug open until i am sure

#3 Updated by ben leinfelder about 10 years ago

closing for now

#4 Updated by Redmine Admin over 6 years ago

Original Bugzilla ID was 4228

Also available in: Atom PDF