1

A couple of checks that have been voided by the claim handler have encountered a Illegal State Exception in one of our workflows. The check is in status Requested and when clicking Void doesn't get set to Pending void instead displays an error This operation could not be completed because the check's status has changed. The status may have been updated by the system or another user. If so, it may take several minutes before you see the update.

The void button is calling Check.VoidCheck() I expect that this function sets the check to pending void at some point but it doesn't happen.

I am unable to reproduce the bug in lower env.

I was unable to locate the logic that sets a check to pending void and re running the workflow or triggering void check again produces the same outcome. Is it possible that the check is stuck somehow, somewhere?

Why is the Check.voidCheck() not setting the check to pending void? is there any condition?

Jakub Petrik
  • 11
  • 2

2 Answers2

5

This error is propagated to you if Check.voidCheck() throws an IllegalStateException. So let's explore this method a bit.

Check.cancelCheck() simply delegates to the voidCheck() method of your CancelCheckMethods implementation. The default implementation of this method is in a class called CancelCheckMethodsImpl.gs. Customers are free to override and customize this behavior though, so you'll want to explore if any changes have been made. If so, this is likely the root cause.

If there are no modifications to this class, then you'll have to dig a bit deeper and look into the three methods that this method delegates to.

    _check.unlinkDeductibles()
    _check.unlinkServiceRequestInvoicesForVoid()
    _check.coreVoidCheck()

This is unfortunately a problem with no obvious solution which will require some investigation. The first thing I'd recommend is that you capture the stack trace in the logs by modifying the behavior in CancelCheckMethodsImpl.voicCheck(), specifically in the catch(). The exception is simply being caught and rethrown, which doesn't give you any insight in the logs about which line is actually throwing the IllegalStateException.

Add to this a logger.error() (or warn(), log(), whatever your preference is, all that matters is that you're using a logger and level which will actually show up in your app server logs) which logs e.stackTraceAsString(). It should look something like this.

} catch ( e : java.lang.Throwable ) {
  _logger.error(e.StackTraceAsString)
  throw e
}

This you may also want to add similar logging to those three methods mentioned above. Then you'll need to redeploy and retest, and after a failure, note the time it occurred, the cluster node upon which it occurred, and pull down the cclog.log from the server around that time. If you post the contents of the stack trace in here, I can help you investigate more deeply once you do that.

Domenick Doran
  • 261
  • 1
  • 7
0

I cannot say for sure what the problem is from the information provided. I would start by copying the production database and running my local codebase against this if possible to be able to debug the issue. I would also try using the ClaimFinancialsAPI voidCheck function to see if this gives you the same error.

If you are running ClaimCenter on the Guidewire Cloud Platform then copying the DB would not be allowed. This error sounds like this check's status is possibly being changed twice within the same bundle somehow. What version of ClaimCenter are you on? I can amend my answer if you can provide the CC version.

SteveDrippsCentricConsulting
  • 106
  • 4