[bug] Missing Metadata in some instance of a workflow

Camunda 8 Topics Discussion & Questions
1

I have started an instance from Zeebe Modeler 0.9.1 and look at the result in Operate 0.23.0.

I see the Metadata of the node:

{
  "activityInstanceId": "2251799813845948",
  "jobType": "scanfolder",
  "jobRetries": 3,
  "jobWorker": "scanfolder",
  "jobDeadline": "2020-08-18T02:06:38.614+0000",
  "jobCustomHeaders": {
    "source": "/mnt/diskstation2/MEDIAS/Bandes-annonces",
    "recursive": "false"
  },
  "jobId": "2251799813845949",
  "startDate": "2020-08-17 16:06:38",
  "endDate": "2020-08-17 16:06:38"
}

Then I modify the “recursive” custom header value in the diagram in Zeebe Modeler, save, then deploy and run it.

The metadata of the new instance of the new version in Operate is empty:

{
  "activityInstanceId": "2251799813846132",
  "startDate": "2020-08-17 16:29:39",
  "endDate": "2020-08-17 16:29:39"
}

If I check the ES index zeebe-record_job_0.23.1_2020-08-17, all necessary information is there…

Any idea ?

2

@vtexier that is a very good question… maybe @svetlana can help us here.
My gut feeling tells me that Operate doesn’t actually need that metadata to show the process state, hence is ignored. Operate is not designed to keep everything, just to provide operational capabilities to the workflows that are running.

3

Hi @vextier,

you see a difference in the information provided by the metadata pop over because the state of the activities you are comparing is different. In you first example the activity was active and a job was waiting for it’s execution. In the second example the activity was already finished as the job for the activity was already completed.

Operate focuses on displaying the current state of the workflow instance to support the user to fix open incidents, it’s doesn’t have the focus to be a full audit tool, i.e. representing every state of the workflow in the past.

So with that in mind, in the first scenario (pending task/job) the user might require the metadata of the currently waiting job. But in the second scenario the job does not exist anymore, so there is also no information to show which can help the user to solve a current incident.

But we are happy to take your feedback on this and would ask you to explain what information of the job (which was completed) you expected to see in the metadata pop over, and why is this information important for you after the activity was finished.

Thanks and have a nice day,
Sebastian

4

Thanks for your reply.

So it is not a bug, it’s a feature ! :wink:

I was pointing this difference in the information as for me the state of the job was not relevant. But I understand perfectly the reason of the choice to focus on pending jobs to resolves incidents.

I do not have any request to change this behavior. In fact, I am focusing now on developing my own database and GUI client to have all the features I was asking for on this forum for Operate or the modeler.

I have realized that to track incidents and recover from failure, workers are first class citizen. So I decided to create my own database of events to handle monitoring and incident recovery from a dedicated client GUI. The workers have all the information needed and before Zeebe so use them to populate a database is more reliable and easier.

Eventually, I will not have the need to use Operate, only the modeler and the broker.

5

@vtexier that’s really cool… if you ever want to share how your operational tools look like, let me know. All feedback from community members is highly valuable and we might want to adopt some of those things later on, maybe in Operate, maybe in different tools.

Cheers

6