quorum-key-manager icon indicating copy to clipboard operation
quorum-key-manager copied to clipboard

[spike] Handle concurrency failures

Open darioAnongba opened this issue 4 years ago • 1 comments

Currently, in the connectors, it is possible that a resource gets created on the underlying store (in the underlying key vault), but the key fails to get added to the DB.

In such a scenario, a retry will fail because the key exists in the Vault by ID. There are multiple solutions to this problem but the goal of this ticket is to discuss them and choose one:

Solutions:

  • Do not correlate the ID of the QKM with the ID of the vault and generate a new ID when creating a new key. In such a scenario, it is possible that keys get created on the underlying vault but retrying will work as the ID will be different.
  • Delete key in vault if it fails to get added to the DB
  • ?

darioAnongba avatar Jul 30 '21 15:07 darioAnongba

if we create in the underlying store but never reference them, they will just leak/pollute the store. I guess we should just delete the key in the backend before leaving the func.

Another idea would be to reuse it for a new key, and link them on a new create. But that require more complexity to keep an "unlinked" set of key somewhere. It's more optimised (if the creation of key is costly), but more complex. I don't think it's worth adding this complexity at this level of the project.

dolanor avatar Jul 30 '21 16:07 dolanor