CSFile.getRelatedTaskIds returning bogus ids

Bill Klish

TeamSite 6.5 SP1
Windows 2003 EE

I encountered some CSObjectNotFoundExceptions while trying to view the properties of files within a workarea. What I found was the following exception being thrown:

com.interwoven.cssdk.common.CSObjectNotFoundException: (Object being looked up was not found)
at com.interwoven.cssdk.workflow.jni.CSWorkflowEngineJNIServer.getTasks(Native Method)
at com.interwoven.cssdk.workflow.jni.WorkflowServiceAdapterImpl.getTasks(WorkflowServiceAdapterImpl.java:227)
at com.interwoven.cssdk.workflow.impl.CSWorkflowEngineImpl.getTasks(CSWorkflowEngineImpl.java:139)
at com.interwoven.ccpro.filesys.properties.file_005fproperties_jsp._jspService(file_005fproperties_jsp.java:677)

After noticing that this exception was attempting to get task information for this file, I did some digging and this file has bogus task ids associated with it. The task ids that are associated are oddly enough for a subworkflow task in a workflow, that is the last task that runs before an end task is reached.

I am not sure why this is happening, but I can reproduce it using multiple files, and roles. What I can't figure out is why the properties link which is using the CSFile.getRelatedTaskIds to get the information to show isn't doing a check to ensure that the task ids that are returned are valid. Instead this exception is thrown. So, the getTasks method should be checking this and ignoring invalid ids. However, I still would like to know why this is happening.

I realize that the task ids should be cleared when the workflow ends, but apparently they are not.

Doing a check of the iwevents.log, I notice something strange. The main workflow is being inactivated before the sub workflow. I could see how this would lead to the issue. Any idea why or how this could be possible?

Bill Klish

This has been filed as a bug. The way the sub workflow tasks are handled using the CS SDK and Workflow Engine seems to be inconsistent. I am working with support on trying to get to the root cause of this, but there seems to be a disconnect between the workflow engine and the cs sdk for these tasks (control is returned to the application before the sub workflow task is fully activated, and the parent workflow can finish before the child workflow).

I will update if a resolution is found.