Confusing ConcurrencyException

[enumag]

Recently we encountered some cases of Prooph\EventStore\Exception\ConcurrencyException (thrown here).

From the name we thought the EventStore failed because there was some other process already working with it, but that wasn't the case. After I added some debug code to dump $statement->errorInfo() the cause was more clear:

array(3) {
  [0] =>
  string(5) "23505"
  [1] =>
  int(7)
  [2] =>
  string(355) "ERROR:  duplicate key value violates unique constraint "_c1455064a23e9da532a1f0248b49e1d402af81f4_expr_expr1_expr2_idx"
DETAIL:  Key ((metadata ->> '_aggregate_type'::text), (metadata ->> '_aggregate_id'::text), (metadata ->> '_aggregate_version'::text))=(App\RealtyRegistration\DomainModel\Realty, e2eb56d1-4705-4210-acb7-39112a4f69c5, 1) already exists."
}

Based on that I found out that we had an error in our testing data which caused one UUID to be accidentally used for two aggregates - trying to insert the second one caused the exception.

While this was entirely our fault, I have a problem with the exception.

• First the name suggests a different cause than the actual problem.
• Second there is no message so you don't even know the UUID of the failing aggregate without debugging.
• Third the exception is caught in ActionEventEmitterEventStore and thrown again later, but it's a new instance so the stack trace of the original exception is lost.

I don't have any idea for improving the third point but we can surely do something about the first two. However since the exception is triggered by two different database error codes (23000 and 23505) I'm not entirely sure if the issue I encountered is the only one that can trigger it. That's why I'd like to discuss this first before sending a PR. Can you give me some insight from your perspective for what this exception is about and why is it named the way it is?

[prolic]

When aggregate type and version already exists, throw concurrency exception. On duplicate event id, we can throw another exception. Not sure if we have enough information which event made the exception if we append multiple events at once.

…

On Thu, Jun 7, 2018, 18:25 Jáchym Toušek ***@***.***> wrote: Recently we encountered some cases of Prooph\EventStore\Exception\ConcurrencyException (thrown here <https://github.com/prooph/pdo-event-store/blob/c3e925cf1c8b169b753e363a602a728e1e1c1aee/src/PostgresEventStore.php#L221> ). From the name we thought the EventStore failed because there was some other process already working with it, but that wasn't the case. After I added some debug code to dump $statement->errorInfo() the cause was more clear: array(3) { [0] => string(5) "23505" [1] => int(7) [2] => string(355) "ERROR: duplicate key value violates unique constraint "_c1455064a23e9da532a1f0248b49e1d402af81f4_expr_expr1_expr2_idx" DETAIL: Key ((metadata ->> '_aggregate_type'::text), (metadata ->> '_aggregate_id'::text), (metadata ->> '_aggregate_version'::text))=(App\RealtyRegistration\DomainModel\Realty, e2eb56d1-4705-4210-acb7-39112a4f69c5, 1) already exists." } Based on that I found out that we had an error in our testing data which caused one UUID to be accidentally used for two aggregates - trying to insert the second one caused the exception. While this was entirely our fault, I have a problem with the exception. - First the name suggests a different cause than the actual problem. - Second there is no message so you don't even know the UUID of the failing aggregate. - Third the exception is caught in ActionEventEmitterEventStore and thrown again later, but it's a new instance so the stack trace of the original exception is lost. I don't have any idea for improving the third point but we can surely do something about the others. However since the exception is triggered by two different database error codes (23000 and 23505) I'm not entirely sure if the issue I encountered is the only one that can trigger it. That's why I'd like to discuss this first before sending a PR. Can you give me some insight from your perspective for what this exception is about and why is it named the way it is? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#161>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAYEvF6Hq5XyOlVrr0mZ89g5-D51yUgSks5t6P-BgaJpZM4UeJDY> .