The "more user friendly  and less destructive response" should appear in the jBPM Console.

Will be made configurable once the fix for BZ-767596 is merged in:
https://github.com/droolsjbpm/jbpm/pull/68

Update status to ON_QA. Please verify them against ER6.

This still happens. Perhaps the fix was not merged? Or not picked up for the ER6?
I can't find it in the product repo. Ryan, do you think you could perhaps look into it a bit? (Added rzhang to CC)

The fix in comment2 has been picked in product branch. Well I can also see the issue still happens to ER6.
This issue needs double check by developer.

Saw this commit in product branch:
commit 6156fd9b6b35af2eca8fc26b64b6b4c1814ebc9e
Author: Maciej Swiderski <mswiders>
Date:   Thu Mar 15 19:53:14 2012 +0100

    BZ-767596 Submitting Human Task with potential owner that is not known to the HT service results with Hibernate exception, enhancement to notify engine in case of errors on HT side so handler can perform
    (cherry picked from commit ba71191ae42d87441150cdd6a6767f75665cb294)

The error (raw error from hibernate) will be still in the logs as this could be important for task server administrator, at the end of the log you should see more meaningful information logged by human task work item handler that should be similar to following:

Error when creating task on task server for work item id 11. Error reported by task server: Command AddTaskRequest faild due to Could not commit transaction. Please contact task server administrator.
java.lang.RuntimeException: Command AddTaskRequest faild due to Could not commit transaction. Please contact task server administrator.

Both errors will be visible only if runtime engine and task server run on the same server. So if they will be separated runtime engine should only have short information logged by the handler.

Could you please confirm this and if that is enough?

(In reply to comment #6)
> The error (raw error from hibernate) will be still in the logs as this could be
> important for task server administrator, at the end of the log you should see
> more meaningful information logged by human task work item handler that should
> be similar to following:
> 
> Error when creating task on task server for work item id 11. Error reported by
> task server: Command AddTaskRequest faild due to Could not commit transaction.
> Please contact task server administrator.
> java.lang.RuntimeException: Command AddTaskRequest faild due to Could not
> commit transaction. Please contact task server administrator.
> 
> Both errors will be visible only if runtime engine and task server run on the
> same server. So if they will be separated runtime engine should only have short
> information logged by the handler.
> 
> Could you please confirm this and if that is enough?


This does not really say much to the user. "Could not commit transaction" is still very far from "This user does not exist" or something, which would actually tell the user what's going on. The problem is not that the transaction...whatever, the problem is, that the HT service does not know the user. Also, the user would only see that message if he looked (and could actually look) into the server log, which is not guaranteed. 
Ideal situation would be: if someone tries to assign a task to a non-existent user, it is not assigned (or it gets assigned to some dummy user) and the user gets some message about it in the jBPM Console. It of course should not break anything else and it should be possible to delete the process or terminate it without:
ERROR [TaskServerHandler] No entity found for query
javax.persistence.NoResultException: No entity found for query
	at org.hibernate.ejb.QueryImpl.getSingleResult(QueryImpl.java:132)
...

Does it make sense like this?


With ER6, I get this in the server log (this is exactly 270 lines long and though there is the new error at the end, it only serves to confuse me more after all of this when trying to see what is wrong):

ERROR [JDBCExceptionReporter] Integrity constraint violation - no parent FK27A9A59E619A0 table: TASK in statement [update Task set allowedToDelegate=?, taskInitiator_id=?, priority=?, activationTime=?, actualOwner_id=?, createdBy_id=?, createdOn=?, documentAccessType=?, documentContentId=?, documentType=?, expirationTime=?, faultAccessType=?, faultContentId=?, faultName=?, faultType=?, outputAccessType=?, outputContentId=?, outputType=?, parentId=?, previousStatus=?, processId=?, processInstanceId=?, processSessionId=?, skipable=?, status=?, workItemId=?, OPTLOCK=? where id=? and OPTLOCK=?]
15:40:59,821 ERROR [AbstractFlushingEventListener] Could not synchronize database state with session
org.hibernate.exception.ConstraintViolationException: could not update: [org.jbpm.task.Task#1]
...
Caused by: java.sql.SQLException: Integrity constraint violation - no parent FK27A9A59E619A0 table: TASK in statement [update Task set allowedToDelegate=?, taskInitiator_id=?, priority=?, activationTime=?, actualOwner_id=?, createdBy_id=?, createdOn=?, documentAccessType=?, documentContentId=?, documentType=?, expirationTime=?, faultAccessType=?, faultContentId=?, faultName=?, faultType=?, outputAccessType=?, outputContentId=?, outputType=?, parentId=?, previousStatus=?, processId=?, processInstanceId=?, processSessionId=?, skipable=?, status=?, workItemId=?, OPTLOCK=? where id=? and OPTLOCK=?]
	at org.hsqldb.jdbc.Util.throwError(Unknown Source)
...
WARN  [TaskLocalTransactionManager] Unable to begin transaction
javax.persistence.RollbackException: Error while commiting the transaction
	at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:71)
...
Caused by: org.hibernate.exception.ConstraintViolationException: could not update: [org.jbpm.task.Task#1]
	at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:94)
...
Caused by: java.sql.SQLException: Integrity constraint violation - no parent FK27A9A59E619A0 table: TASK in statement [update Task set allowedToDelegate=?, taskInitiator_id=?, priority=?, activationTime=?, actualOwner_id=?, createdBy_id=?, createdOn=?, documentAccessType=?, documentContentId=?, documentType=?, expirationTime=?, faultAccessType=?, faultContentId=?, faultName=?, faultType=?, outputAccessType=?, outputContentId=?, outputType=?, parentId=?, previousStatus=?, processId=?, processInstanceId=?, processSessionId=?, skipable=?, status=?, workItemId=?, OPTLOCK=? where id=? and OPTLOCK=?]
	at org.hsqldb.jdbc.Util.throwError(Unknown Source)
...
ERROR [TaskPersistenceManager] Unable to commit.
java.lang.RuntimeException: Unable to commit transaction
	at org.jbpm.task.service.persistence.TaskLocalTransactionManager.commit(TaskLocalTransactionManager.java:42)
...
Caused by: javax.persistence.RollbackException: Error while commiting the transaction
	at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:71)
	at org.jbpm.task.service.persistence.TaskLocalTransactionManager.commit(TaskLocalTransactionManager.java:39)
	... 30 more
Caused by: org.hibernate.exception.ConstraintViolationException: could not update: [org.jbpm.task.Task#1]
	at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:94)
...
Caused by: java.sql.SQLException: Integrity constraint violation - no parent FK27A9A59E619A0 table: TASK in statement [update Task set allowedToDelegate=?, taskInitiator_id=?, priority=?, activationTime=?, actualOwner_id=?, createdBy_id=?, createdOn=?, documentAccessType=?, documentContentId=?, documentType=?, expirationTime=?, faultAccessType=?, faultContentId=?, faultName=?, faultType=?, outputAccessType=?, outputContentId=?, outputType=?, parentId=?, previousStatus=?, processId=?, processInstanceId=?, processSessionId=?, skipable=?, status=?, workItemId=?, OPTLOCK=? where id=? and OPTLOCK=?]
	at org.hsqldb.jdbc.Util.throwError(Unknown Source)
...
ERROR [TaskServerHandler] Could not commit transaction
java.lang.RuntimeException: Could not commit transaction
	at org.jbpm.task.service.TaskServiceSession.doOperationInTransaction(TaskServiceSession.java:966)
...
Caused by: java.lang.RuntimeException: Unable to commit transaction
	at org.jbpm.task.service.persistence.TaskLocalTransactionManager.commit(TaskLocalTransactionManager.java:42)
...
Caused by: javax.persistence.RollbackException: Error while commiting the transaction
	at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:71)
...
Caused by: org.hibernate.exception.ConstraintViolationException: could not update: [org.jbpm.task.Task#1]
	at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:94)
...
Caused by: java.sql.SQLException: Integrity constraint violation - no parent FK27A9A59E619A0 table: TASK in statement [update Task set allowedToDelegate=?, taskInitiator_id=?, priority=?, activationTime=?, actualOwner_id=?, createdBy_id=?, createdOn=?, documentAccessType=?, documentContentId=?, documentType=?, expirationTime=?, faultAccessType=?, faultContentId=?, faultName=?, faultType=?, outputAccessType=?, outputContentId=?, outputType=?, parentId=?, previousStatus=?, processId=?, processInstanceId=?, processSessionId=?, skipable=?, status=?, workItemId=?, OPTLOCK=? where id=? and OPTLOCK=?]
	at org.hsqldb.jdbc.Util.throwError(Unknown Source)
...
INFO  [LoggingFilter] SENT: HeapBuffer[pos=0 lim=0 cap=0: empty]
ERROR [AsyncWSHumanTaskHandler] Wed May 02 15:41:00 CEST 2012: Error when creating task on task server for work item id 1. Error reported by task server: Command AddTaskRequest faild due to Could not commit transaction. Please contact task server administrator.
java.lang.RuntimeException: Command AddTaskRequest faild due to Could not commit transaction. Please contact task server administrator.
	at org.jbpm.task.service.TaskServerHandler.messageReceived(TaskServerHandler.java:636)
...

In general this message is not for the user but more for administrators. Nevertheless this problem will only occur when task server does not utilize UserGroupCallback as the callback is responsible for user/group verification and it will do pretty much what was described: will filter out users/groups that do not exist and assign it at least to the business administrator. Task server will complain (with an exception) if there are no business administrators at all which is mandatory and defined by WSHT spec.
Task server without UserGroupCallback assumes that all users are groups are loaded in advance and reports the raw exceptions in case this requirement is not met. We could look for every user/group in db to check if user/group exists but for that callback was introduced.

Wdyt?

(In reply to comment #8)
> In general this message is not for the user but more for administrators.

I can agree with that. But it is also the only message telling you that something is wrong. And it is telling the administrator to contact the administrator. ;) If we assume this stack trace is for admins, we don't need to tell them "oops, something went wrong" after the stack trace. The admin will see that it is a HT Service/server problem from the stack trace.

> Nevertheless this problem will only occur when task server does not utilize
> UserGroupCallback as the callback is responsible for user/group verification
> and it will do pretty much what was described: will filter out users/groups
> that do not exist and assign it at least to the business administrator. Task

Without any other message (available to the console user) the user will never know, in case he makes a typo when assigning a task to someone - which can happen very easily. He will assume he entered the right user name.

> server will complain (with an exception) if there are no business
> administrators at all which is mandatory and defined by WSHT spec.

The task server complains even when there is Administrator - who, by the way, can't do anything in this situation in the Console.

> Task server without UserGroupCallback assumes that all users are groups are
> loaded in advance and reports the raw exceptions in case this requirement is
> not met. We could look for every user/group in db to check if user/group exists
> but for that callback was introduced.
> 
> Wdyt?

Yes, that would be a bother. What would make it really nice and helpful is something like "Dear user, the console registered such and such type of exception upon creation of human task. Perhaps the assignee does not exist?" - the user can then look at the process instance details and see that, yes, he entered an incorrect user name. And he can actually do something about it - like terminate the instance or delete it and run some process that will clean up whatever mess this created.


Your thoughts on that?

(In reply to comment #9)
> (In reply to comment #8)
> > In general this message is not for the user but more for administrators.
> 
> I can agree with that. But it is also the only message telling you that
> something is wrong. And it is telling the administrator to contact the
> administrator. ;) If we assume this stack trace is for admins, we don't need to
> tell them "oops, something went wrong" after the stack trace. The admin will
> see that it is a HT Service/server problem from the stack trace.

Unless runtime engine and task server runs on two different servers where stack trace is on one and the short message on the other.
> 
> > Nevertheless this problem will only occur when task server does not utilize
> > UserGroupCallback as the callback is responsible for user/group verification
> > and it will do pretty much what was described: will filter out users/groups
> > that do not exist and assign it at least to the business administrator. Task
> 
> Without any other message (available to the console user) the user will never
> know, in case he makes a typo when assigning a task to someone - which can
> happen very easily. He will assume he entered the right user name.

Due to asynchronous nature of task creation (in most of the cases) user will not be informed about the error on submission time as this will just request to create a task. I think that could be more responsibility of form validation.

> 
> > server will complain (with an exception) if there are no business
> > administrators at all which is mandatory and defined by WSHT spec.
> 
> The task server complains even when there is Administrator - who, by the way,
> can't do anything in this situation in the Console.
Task was not created at all that's why admin can't do anything as well.
> 
> > Task server without UserGroupCallback assumes that all users and groups are
> > loaded in advance and reports the raw exceptions in case this requirement is
> > not met. We could look for every user/group in db to check if user/group exists
> > but for that callback was introduced.
> > 
> > Wdyt?
> 
> Yes, that would be a bother. What would make it really nice and helpful is
> something like "Dear user, the console registered such and such type of
> exception upon creation of human task. Perhaps the assignee does not exist?" -
> the user can then look at the process instance details and see that, yes, he
> entered an incorrect user name. And he can actually do something about it -
> like terminate the instance or delete it and run some process that will clean
> up whatever mess this created.
> 
> 
> Your thoughts on that?
As mentioned inline, we cannot guarantee that for async operations (mina, hornetq, jms) as the response could not be known immediately so such message cannot be presented to the user.
Using task server without usergroupcallback is considered a common use case? Because with the callback task will be created even if user/group is not known by simply excluding those unknown.

Any comments? I was wondering if we can keep this as is for now and take that into account when improving human task module which should take place very soon.

Yes, I was thinking about this whenever I had time.
Basically, it is in a state where getting the user name wrong does not destroy the whole thing. It seems.
Using usergroupcallback avoids those exceptions, true, but we do allow people not to use it. And it should work without that too.
And the point is, nobody will know that the task was not created at all or was created for a wrong user name. That's what bothers me. If you do something wrong, you usually want to know and as soon as possible.
It's good to know you counted with the possibility of the Task Service being on another server.

Okay, let's try a different approach. Would it be possible to just add the short message from human task work item handler to the message log in the console? Would it be possible to log a message there also when using the usergroupcallback in case the specified user or group don't exist? Even if the user does not get that immediately, it is still better than not getting it at all I think.

If this can't be done, than I guess we'll have to leave it as it is. I'd keep this bug on ASSIGNED and wait for that human task module improvement. And perhaps we need someone else's opinion on this too?

The usergroupcallback is specifically designed to make sure you can validate whether a user / group name is valid or not.  While it is possible to use the task service without callback, I believe it is probably recommended to register one.

I believe the fixes related to this issue already solve the most important part of the problem.  The issue that is currently described is inherent to a process that is invoking external services in an asynchronous way.  In that case, it is impossible to immediately return feedback (like for example the invocation of the service failed), and the handler is responsible for handling exceptions itself.  In general that means it should try to handle most exceptions itself (for example assign the task to an admin if the user is unknown), but a wide range of possibilities is available (abort the work item, create a business level exception that is managed by the process, etc.).  The human task handler already allows defining these different strategies, and tries to handle exceptions gracefully.

Only if the user is not using a usergroupcallback to do validation, and an invalid user is created, and exception will be logged into the human task server log, and the task will not be created.  But unfortunately there's not much else we can do.

I believe the solution to this will be to execute part of the task functionality synchronously (more specifically the task creation and task completion), so that the handler can immediately respond to failures like this.  This will only be available in the next version however.

I would therefore like to propose the following solution:
 - recommend users to use a usergroupcallback to define valid users / groups and integrate it with a system that maintains user group relationships
 - in a future version of BRMS, make task creation synchronous so that these errors can be managed more easily

I'm proposing the postpone this issue for now, and I'm setting devel_ack- as a result of this.  Please let me know if this would be a problem.

(In reply to comment #13)
> Only if the user is not using a usergroupcallback to do validation, and an
> invalid user is created, and exception will be logged into the human task
> server log, and the task will not be created.  But unfortunately there's not
> much else we can do.

I believe we can live with that for the time being. Although please keep this issue in mind for future releases.

*** Bug 818936 has been marked as a duplicate of this bug. ***

Kris, Maciej, Rajesh we have customers requiring an improvement to these messages. The current content is not enough to identify by log files which is the real cause.

Please, really consider this.

Customer words:
"(...) the issue is that we can't rely on a customer's process definition from specifying a userId that has not been added to the system.  When the error happens it is the runtime exception that occurs that is meaningless to our application, which means that we can't give any kind of meaningful feedback to the caller.

We already have a service call that the customer can use to add users and groups using the method described.  However we can't rely on the customer actually adding them which is the reason the error can occur.  The jBPM/BRMS api should throw a meaningful exception which production ready code would do"

Thanks

What is the status of this issue?

it's scheduled to be included for 6.0 version