Hi.
We’ve noticed a change in the exception message caught in the exception flow when a unique index restriction is violated in the database. Previously, the error message was:
"Cannot insert duplicate key row in object (...) with unique index (...). The duplicate key value is (...)."
However, it now appears as:
"Error executing query."
The full error message still appears in the service center, but it is no longer available in the exception flow.
Impact
Our code relies on detecting this specific error for custom exception handling. This change affects our ability to differentiate unique index violations from other database errors, which has a significant impact on our logic.
Questions
Looking forward to your insights.
Best regards,
André Dinis
I remember the detailed error message poping up for unhandled exceptions but now replaced with "Error executing query.". Not sure when was this implemented. You can find similar discussion at
btw Handling errors purely based on exception text may be unreliable. Maybe it's time to refactor the code.
Hi Siya,
First of all, thanks for your response.
I completely understand that handling exceptions based on the exception message is unreliable, and the issue we're facing is a perfect example—the message changed, and now our logic no longer works as expected.
That said, I’d like to explain our use case and why we’re doing this.
We synchronize data from external systems to our application using Kafka events and LightBPTs. When an external system sends a Kafka event, our application processes it using LightBPTs. Since multiple messages for the same Kafka topic can arrive simultaneously, two instances of the process may try to create the same record at the same time. This results in a duplicate key error.
If this specific error occurs, we want to handle it differently and avoid logging it excessively to prevent cluttering the service center, as it happens frequently. Unfortunately, we can't fully prevent the exception—validating before CreateOrUpdate doesn’t help because both processes may see that the record doesn’t exist and still attempt to create it.
Let me know your thoughts!
Hello @André Dinis,
I missed responding to you earlier.
You mentioned that: "When an external system sends a Kafka event, our application processes it using LightBPTs."
Just to clarify, does this mean you have exposed REST endpoints that are triggered by Kafka events, and these endpoints insert an entry into a table (say X)? If two identical messages are sent to the REST endpoint, does the second attempt fail due to a unique constraint violation?
If that’s the case, you can safely ignore the exception since the data already exists. A possible approach is to log such occurrences in a separate entity and reconcile them later if needed.
However, the database exception would occur at the point of insertion in the REST API logic—before the LightBPT process even starts. LightBPT execution only begins after the database insert triggers the process.
Let me know if my understanding is correct or if there’s a different scenario at play.
Hello @Siya,
Yes, that's right. We have exposed a REST endpoint triggered by Kafka events, this endpoint inserts an entry into a table, and sometimes, we have errors due to a unique constraint violation when two different events try to create the same record.
Ignoring the exception does not seem right as it may be another type of database exception.
Wow this is very interesting, now what should we consider when refactoring code or writing new code for these type of error handling ? @Siya, can you share more detail or where we can find these details ?
One option would be to do an extra read in the exception handler, and if the duplicate is found, you know that was the reason for the exception, otherwise, you raise the same exception again to still escalate all other database errors.
We will use your suggestion for now, but no 100% guarantee finding the record in that extra read in the exception handler means that the error was a duplicate key, does it?
No, it could be that besides it being a duplicate, there is something else going wrong. But in case of a duplicate you want to do XXXX, does it matter at that point what the real exception was ??
I don't know exactly what XXX is, but for example, if you want to skip the processing of the message in case of duplicate, then why care whether that was the actual error, odds are really large that it was, though.
I'm facing the same issue!