act_hi_actinst - userTask and taskId?

[dognose]

Hello,

in our act_hi_actinst table, we have aprox 10.000 entries of the type userTask by now.
However there are about 400 entries of the type "userTask", that have taskId set to null…

SELECT * 
FROM  `act_hi_actinst` 
WHERE ACT_TYPE_ =  'userTask'
AND ISNULL( TASK_ID_ ) 
‍‍‍‍‍‍

I compared the times of those entries, and figured out, that all those entries have been created
during the time we have been using activiti 5.12. (now Running 5.13)

So, is there any chance that there is a update step, we missed?
Was this a known bug in Activiti 5.12?

—

Would it be save to "rebuild" those missing values? Or is Activiti internally threating "old" activiti instances different,
and requires that id to be null?

I noticed, that all Tasks are available in the act_hi_taskinst table.

So, I would aquire the taskId from there.
After joining the tables on executionid, proc_inst_id and activiti_name i noticed, that this is not enough, if a task has been executed
two (or more) times within the same process.

But i was able to match on the Start_time also, which seems to produce the correct result.

The following query will perform the readout of both Task_ids:

- fetched directly from act_hi_actinst
- fetched from act_hi_taskinst, using the described join.

SELECT 
   aha.ID_ ,
   aha.PROC_INST_ID_,
   aha.EXECUTION_ID_,
   aha.ACT_NAME_,
    aha.TASK_ID_ AS TASK_ID_FROM_ACTIVITI_,
    aht.ID_ AS TASK_ID_FROM_TASK_TABLE_
FROM 
    `act_hi_actinst` aha 
LEFT JOIN
    `act_hi_taskinst` aht
ON
   aha.PROC_INST_ID_ = aht.PROC_INST_ID_ AND
    aha.ACT_NAME_ = aht.NAME_ AND
    aha.START_TIME_ = aht.START_TIME_
WHERE 
   aha.ACT_TYPE_ = 'userTask'
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

For me that are 10.880 rows in total. So, now both TaskId columns SHOULD be equal OR produce null on the TASK_ID_FROM_ACTIVITI_ variable.

However, i found some entries, having both ids given as Null. This means, that the join could not find the propert task in act_hi_taskinst,
when taking process id, act_name and starttime as a join condition. Narrowing down the query to "those":

SELECT * FROM (SELECT 
   aha.ID_ ,
   aha.PROC_INST_ID_,
   aha.EXECUTION_ID_,
   aha.ACT_NAME_,
    aha.START_TIME_,
    aha.TASK_ID_ AS TASK_ID_FROM_ACTIVITI_,
    aht.ID_ AS TASK_ID_FROM_TASK_TABLE_
FROM 
    `act_hi_actinst` aha 
LEFT JOIN
    `act_hi_taskinst` aht
ON
   aha.PROC_INST_ID_ = aht.PROC_INST_ID_ AND
    aha.ACT_NAME_ = aht.NAME_ AND
    aha.START_TIME_ = aht.START_TIME_
WHERE 
   aha.ACT_TYPE_ = 'userTask'
) as temp
WHERE 
   ISNULL(TASK_ID_FROM_TASK_TABLE_) 
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Those didn't match, because the Execution Time was slightly different (+/- some seconds)

However, not matching on completion time would cause more troubles, because one task can be completed multiple times
within some processes…

And for the very same reason it is quite hard to use a tolerance on the completion time to match the proper taskId.
(Assignee could also be equal for this problem, therefore doesn't provide any additional constraint)

So, how to rebuild the missing taskIDs best ?

[dognose]

ps.: How do edit the post? Manual linebreaks are wrapped unnice, hard to read

[dognose]

I now performed the following update (on the test system) to update those values, for which the condition matches:


UPDATE `act_hi_actinst` aha
INNER JOIN `act_hi_taskinst` aht
ON
  aha.PROC_INST_ID_ = aht.PROC_INST_ID_ AND
  aha.ACT_NAME_ = aht.NAME_ AND
  aha.START_TIME_ = aht.START_TIME_
SET aha.TASK_ID_ = aht.ID_
WHERE
aha.ACT_TYPE_ = 'userTask' AND
ISNULL(aha.TASK_ID_) AND NOT ISNULL(aht.ID_);

Finally, a total of 5 tasks have been left over where the Completion time was +/-1 seconds in both tables.

So, I could fix those manually.

Core question remains: Would it be save to reinsert the missing TaskIDs in act_hi_actinst, or is activity (internaly) knowing, that these are processes from 5.12 and assuming the field to be 'null'?

[dognose]

Loaded an old dump from 5.12 - there the column hasn't even been there in act_hi_varinst.
So its not a "bug", but simple the fact, that after the update of the db scheme, all the taskId fields for "5.12-activiti-instances" are null.

[jbarrez]

wow you did some nice investigation yourselves there!

However I'm not following completely your explanation above … this is what I found :

- The table ACT_HI_VARINST was introduced in 5.11 upgrade
- The TASK_ID_  column of ACT_HI_ACTINST was also introduced in 5.11 upgrade

So that doesn't seem to match what you found, right?

Regarding to your question:

"Core question remains: Would it be save to reinsert the missing TaskIDs in act_hi_actinst, or is activity (internaly) knowing, that these are processes from 5.12 and assuming the field to be 'null'?"

Yes it is safe. Once created, Activiti will not use these values anymore (except for updates, but it can handle nulls)

[dognose]

Hi,

you are right - it was 5.10 we used prior: Scheme History says: create(5.10) upgrade(5.10->5.13)

Alright, then that's the reason. So i'll go with updating the missing variables.

Thx for the quick response.

Sidenode: >>Those didn't match, because the START_TIME_ was slightly different (+/- 1 second)<< shouldn't those be equal in any case?
(Assuming you are using NOW() in the queries, so it might be a issue, when the start happens around 490-510 ms of a second due to internal rounding)

[dognose]

On another sidenode: >>Yes it is safe. Once created, Activiti will not use these values anymore<<

We encountered the problems, when using the following statement:


HistoricActivityInstance activityInstance = this.historyService.createHistoricActivityInstanceQuery()
     .activityInstanceId(processVar.getActualInstance().getActivityInstanceId()).singleResult();

The returned activitiInstance has task id null for the mentioned processes.

Reason:
We are using processvariables on a "process" Scope (businessProcess.setVariable) and not on the task Scope (businessProcess.setTaskVariable)

This means (assuming it is because of that), that act_hi_detail has always taskId `null`. To know, in which Task a variable has been changed, we are using the HistoricActivitiyInstance service to determine the taskID based on the activitiid provided by the act_hi_detail table. And there, we are getting taskId `null`, when its not set inside the act_hi_actinst table.

(So, maybe its not used by activiti - but its available using the services exposed in the public API.)

[jbarrez]

Ok, that last use case makes sense. Indeed in that case it would be an issue if you use it like that

"Those didn't match, because the START_TIME_ was slightly different (+/- 1 second)<< shouldn't those be equal in any case?"

I'm not following that, can you explain?

[sakthi1970]

I noticed the difference in the millosecond between table ACT_RU_TASK column CREATE_TIME_ and ACT_HI_TASKINST column START_TIME_ .. say out of 176 records, i found 7 had that difference. It would have been best if the main table ACT_RU_TASK or ACT_HI_TASKINST start time is used to update the other table. They probably used sysdate or something. I'm using ORACLE.

Is there a patch or a way to ensure its always in sync ?

[jbarrez]

It's probably because time actually moved on when those two datas are made … I agree it would maybe be better to have them in sync

> Is there a patch or a way to ensure its always in sync ?

um. you just found it… how would there be a patch already?
If it's a problem for you, you either create an issue so we can track or you fix it and create a pull request