Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add idempotency field #1573

Open
4 of 5 tasks
elsand opened this issue Dec 9, 2024 · 0 comments
Open
4 of 5 tasks

Add idempotency field #1573

elsand opened this issue Dec 9, 2024 · 0 comments
Assignees

Comments

@elsand
Copy link
Collaborator

elsand commented Dec 9, 2024

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

Preview Give feedback

Threat modelling

Preview Give feedback

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Doing
Development

No branches or pull requests

2 participants