Project

General

Profile

Actions

Bug #4228

closed

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

Added by ben leinfelder over 15 years ago. Updated over 15 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 bugResolvedben leinfelder06/29/2009

Actions
Actions #1

Updated by Christopher Brooks over 15 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?

Actions #2

Updated by ben leinfelder over 15 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

Actions #3

Updated by ben leinfelder over 15 years ago

closing for now

Actions #4

Updated by Redmine Admin over 11 years ago

Original Bugzilla ID was 4228

Actions

Also available in: Atom PDF