@CharanS25

Please can you narrow down the issue:

1.  Is the on-screen error not actually causing any functionality issues?

2  Can you tell us what troubleshooting you have already carried out?

3  Please provide screenshots and details of the exact error seen in PegaRules and Alert logs.

4  Can you replicate this for all work items, new and old?5 

5. Can you carry out the suggestion listed in the error: set Initialization/UniqueActivityTerminateExceptions = true?

6  What does your OnClick event for open assignment actually do? 

What is the full activity configuration?

Are you using a Customized PerformDefaults activity using Activity-End method? 

We have seen issues where users had implement a Validate rule that applies to an activity such as uploading attachments which did  not contain any checks for passivated input streams and caused a generic error with the wrong harness being called.  Another incorrect scenario is where the user changed the PerformDefaults Activity in order to show the user more details when they are not authorized to perform an assignment. For example by calling  Activity-End to stop the calling Activities and use a custom Harness but now in a new Pega version it is replaced by Pega's HarnessFail and there is an exception displayed to the user.   

As of Pega 7.x versions this will show generic harness failure message if there is some exception occurs during opening of assignment.

Instead of using activity-end method could you rely on parameter or step status by setting them explicitly which takes care of avoiding the execution in further control flow and eventually when the control flow returns to doUIAction activity no exception would be caught and the harness would be displayed . 

  The use of exit-activity is inappropriate where it is being used, and the resulting error message is expected. Basically your insertion of Activity-End is short-circuiting a large portion of the processing (you can examine the stack trace to see all of the activities that are getting aborted), with the result that the thrown exception is being displayed on the screen. Most likely it is an error handler further down in the stack that has no idea what has happened, and is just repeating to the end user the exception that you see. In a nutshell, what worked for you back in the 6 series may no longer be compatible with the architecture of the 7 series. 

Please see the following support article SA-34920 . and      SA-99038 

Please re-work your customization to rework the application to find some other way to achieve the desired result.

If you need further help I would suggest that you log a support incident for this and please let us know the INC number so that we can help track this with you.