You are viewing limited content. For full access, please sign in.

Discussion

Discussion

Forms - The submission data does not match the current variables assigned to this process.

Forms
Updated April 15, 2022
posted on October 19, 2020

The process is being terminated for this reason. It is correct, they did add a new variable, which was not there when the process was started, but the question I have is why is this a reason for termination?

They added a new field to one of the user task's assigned forms and now when the process tries to assign that task it decides it is best to terminate the entire process and all future tasks, a new field will always require a new variable what's the big deal that it did not exist before?

I don't see any reason to terminate.

0 0
replied on April 15, 2022

We have improved the error handling when the submission contains deleted variable in Forms 11. The instance will not terminate any more and the deleted variable will be ignored. 

1 0
replied on October 19, 2020

Hi Chad,

I agree that instance should not be terminated under described situation. There might be a bug.

What version of Forms are you on? Could you share the full error message include stack trace? Can the termination issue be reproduce with a simple process?

0 0
View 4 previous replies
replied on October 20, 2020

Version 10.4.1.224

Below is the full error. I can not reproduce it by creating a test environment where I submit to a hold task which is followed by a "should terminate" task. Then go into the form assigned to the "should terminate" task and add a new field before proceeding. Everything works fine when I do this.

I just looked for the first variable on the form used in the task that is terminating, that does not exist in the variables tab of the monitor history. Am I looking at the wrong thing? It says submission data does not match the current variables. I assumed that meant they added a field that did not exist when the instance was started.

The submission data does not match the current variables assigned to this process. [LFF708-SubmissionDataIsInvalid]

Details:
URL: 
Error: SubmissionDataIsInvalid
Date: 10/16/2020 3:45:16 PM (Pacific Standard Time)
HTTP Status Code: 500
Business Process ID: 39
Instance ID: 35477
Business Process Name: Utility Payment Assistance Application

Stack Trace:
Caught exception: Laserfiche.Forms.CommonUtils.Exceptions.LFFormsException
Message: The submission data does not match the current variables assigned to this process. [LFF708-SubmissionDataIsInvalid]
   at Laserfiche.Forms.Routing.FlowObject.AddSubmissionData(IEntityContext appContext, cf_submissions submission, SubmissionAttributeData[] attributeDataSet, SubmissionHeaderData submissionHeaderData)
   at Laserfiche.Forms.Routing.Activity.ProcessSubmissionDataForNewSubmission(SubmissionHeaderData submissionHeaderData, SubmissionAttributeData[] submissionAttributeDataSet, cf_submissions submission)
   at Laserfiche.Forms.Routing.Activity.UpdateDataForMainProcessInstance(cf_bp_worker_instances processInstance, IRoutingContext routingContext)
   at Laserfiche.Forms.Routing.UserTask.ExecuteForReEntry(cf_bp_worker_instances processInstance, IRoutingContext routingContext)
   at Laserfiche.Forms.Routing.UserTask.Execute(Int32 instanceId, IRoutingContext routingContext)
   at Laserfiche.Forms.Routing.RoutingDispatcher.ExecuteSteps(Int32 processWorkerInstanceId)

 

0 0
replied on October 22, 2020

Hi Chad,

I can reproduce the terminate issue according to your description. The variable is actually deleted.

The issue happens when variable got deleted after user task is submitted and before routing service processes it, which may happen when routing service is busy.

 

I have filed a bug and we will do further investigation. Thanks for reporting!

0 0
replied on October 22, 2020

Oh one thing that doesn't match our environment though, since the user made the change, every process fails when assigning the next user task (that had been started before the change), over many many days there are many terminations.

0 0
replied on October 23, 2020

By 'fails when assigning the next user task', do you mean that the next user task is never assigned to anyone and directly terminate? In instance monitor page, is there 'The task was assigned to forms' under the terminated user task?

If yes, what the step before the problematic user task?

 

If it is never assigned and thus no submission, I don't think Forms will execute the user task step and throw the error from ExecuteSteps function (last line). Is there any other error reported when user task is terminated?

0 0
replied on October 26, 2020

The next user task is never assigned to anyone. It terminates while assigning that task because the variables no longer match.

The task it was on before this was another user task, with a different form assigned to it.

There is no task was assigned to forms, or anyone, it just terminates as soon as it reaches this step for any submissions that were started before they modified the fields on the form.

It doesn't even give us a chance to restore the variable and re-assign, usually it would suspend and never terminate unless we manually give the OK to terminate or if we create an impossible routing decision somewhere in the pathing.

Also even if a new variable was added, or an existing one deleted, why is that a matter, since no field would be there to try to show a deleted variable, a field can't exist without a variable.

0 0
replied on October 27, 2020

I couldn't reproduce your case. Please open up support case if you would like team to take further investigation. More information like instance details/business process/database may be inquired. And script can be provided if you would like to resume those terminated user task.

0 0
replied on October 28, 2020

I think the biggest issue is that it does not say which variable doesn't match, so this entire time I have been working off the assumption of the variable I found on the form which is not in the variables tab of the monitor information.

All the instances that were started before the update have now been terminated, so new instances are working.

I think we are good for now unless it happens again. The biggest feature improvement I could use is more specifics on which variable(s) it is not happy with when this error is thrown. Just like when we have a field violation, where it tells us which field is the problem field.

3 0
You are not allowed to follow up in this post.

Sign in to reply to this post.

Details
Related Posts
Loading ...