You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This will allow service providers to attempt to create dialogs supplying a custom idempotency key in the request body. This will have to be unique per org (ie serviceowner code). The field should only be visible on service owner DTOs (for create and get details). If attempting to create a dialog which collides on this field, an error should be returned. This error should also indicate the id of the existing/conflicting dialog.
Implementation
For performance reasons, we should avoid having to manually check whether the org/key already exists prior to database insertion. Instead, consider creating a composite unique key over "org" and the new field for idempotency key, and handle the constraint error instead.
The content you are editing has changed. Please copy your edits and refresh the page.
This introduces a mechanism in which it is possible for any system to determine if a dialog exists, if the format/business rules for the utilized idempotency keys are known and predictable. This is mostly mitigated by having this unique per org. Trust boundaries will however eventually be set per system within an org (see #40), so documentation should mention this and suggest to consider using non-predictable idempotency keys (ie peppered hashes) if systems within an org does not trust each other to leak the existance of dialogs to eachother.
Acceptance criteria
GIVEN a service owner DTO with a valid idempotency key and no existing dialog with the same idempotency key for the same org WHEN a dialog is created THEN the dialog is successfully created, and the idempotency key is stored in the database
GIVEN a service owner DTO with a valid idempotency key that matches an existing dialog's idempotency key for the same org WHEN a dialog creation is attempted THEN the service returns an error indicating a conflict, including the ID of the existing dialog
GIVEN a service owner DTO with an invalid idempotency key (e.g., exceeding maximum length or malformed) WHEN a dialog creation is attempted THEN the service returns a validation error indicating the issue
The text was updated successfully, but these errors were encountered:
Introduction
This introduces an independent idempotency mechanism as a field on the dialog entity
Description
See initial discussion in #1191
This will allow service providers to attempt to create dialogs supplying a custom idempotency key in the request body. This will have to be unique per org (ie serviceowner code). The field should only be visible on service owner DTOs (for create and get details). If attempting to create a dialog which collides on this field, an error should be returned. This error should also indicate the id of the existing/conflicting dialog.
Implementation
For performance reasons, we should avoid having to manually check whether the org/key already exists prior to database insertion. Instead, consider creating a composite unique key over "org" and the new field for idempotency key, and handle the constraint error instead.
Tasks
Threat modelling
Threats
This introduces a mechanism in which it is possible for any system to determine if a dialog exists, if the format/business rules for the utilized idempotency keys are known and predictable. This is mostly mitigated by having this unique per org. Trust boundaries will however eventually be set per system within an org (see #40), so documentation should mention this and suggest to consider using non-predictable idempotency keys (ie peppered hashes) if systems within an org does not trust each other to leak the existance of dialogs to eachother.
Acceptance criteria
GIVEN a service owner DTO with a valid idempotency key and no existing dialog with the same idempotency key for the same org
WHEN a dialog is created
THEN the dialog is successfully created, and the idempotency key is stored in the database
GIVEN a service owner DTO with a valid idempotency key that matches an existing dialog's idempotency key for the same org
WHEN a dialog creation is attempted
THEN the service returns an error indicating a conflict, including the ID of the existing dialog
GIVEN a service owner DTO with an invalid idempotency key (e.g., exceeding maximum length or malformed)
WHEN a dialog creation is attempted
THEN the service returns a validation error indicating the issue
The text was updated successfully, but these errors were encountered: