TwinPermissionsConflictError

Thrown by the twin permission mutation and listing methods on a 409.

The three causes need different handling, which is why they are distinguishable rather than collapsed into one "modified by another user":

• EtagMismatch — the etag is stale; re-read (or use currentState) and retry.
• EtagRequired — the write omitted an etag but the principal already held an entry, so it would have replaced state the caller never read. Retried by reading at all.
• ScopesNotProvisioned — the twin owns no Twinfinity scope, so there is no permission state to read or write. Nothing provisions on read, so retrying will not help.

Hierarchy

• Error
  • TwinPermissionsConflictError

Index

Constructors

• constructor

Properties

• conflictCause
• currentState
• errorBody

Constructors

constructor

• new TwinPermissionsConflictError(message: string, errorBody: TwinPermissionsConflictErrorBody): TwinPermissionsConflictError

• Overrides Error.constructor

  Parameters

  • message: string

  • errorBody: TwinPermissionsConflictErrorBody

  Returns TwinPermissionsConflictError

Properties

publicreadonlyconflictCause

conflictCause: TwinPermissionsConflictCause

Which of the three conflicts this is. Named conflictCause rather than cause so the standard Error.cause — whose consumers expect a wrapped error, not a string — is left alone; the same value is on errorBody.cause.

publicoptionalreadonlycurrentState

currentState?: TwinPrincipalPermissionsGet

The entry as the server holds it, including the etag to retry with.

publicreadonlyerrorBody

errorBody: TwinPermissionsConflictErrorBody