How does iwgetfilejobs work?

While debugging an exception that was being thrown by OpenAPI (see my other post), I discovered that a call to the iwgetfilejobs CLT returned workflow and task IDs that were not valid. (If I ran the iwgetwfobj CLT against these workflow and task IDs, I received responses indicating that these IDs are invalid.)

It appears that these workflow and task IDs are outdated and correspond to workflows/tasks that are no longer active.

Does anyone have any idea how iwgetfilejobs determines which workflow and task IDs to associate with a file, and why it might be returning outdated IDs?

Find more posts tagged with

Comments

james1

The workflow store maintains a registry of path/job/task associations. Normally, when a job completes, this registry is cleared of entries for that job. However, we've seen a couple of cases where the registry contains entries for non-existent jobs and tasks. I don't think we've ever found a direct cause for this. I know of no way to correct that workflow store registry problem. I don't think that iwfsck will correct that problem.

-- James

--
James H Koh
Interwoven Engineering

Adam Stoller

Here's one hypothesis:

If you use (or have used) iwjobc - you can create jobs that are registed in the workflow backing store - but if you've never invoked them - they will not be valid workflows because they have never been instantiated. (This would make sense for invalid jobid's - not sure what would lead to taskids in the system that are invalid).

--fish
(Interwoven Senior Technical Consultant)