Setu-TS
    Preparing search index...

    Class SerializationConflictError

    Thrown when the database rejected a write because a concurrent transaction changed the same data (X38-1, M90f). The operation did not happen and may be retried.

    The condition reaches the client as 409 Conflict — the canonical retryable-signal status — instead of the masked 500 that told a well-behaved client to give up, silently dropping the write and making optimistic concurrency unusable. The original driver error is preserved as cause, so the operator's diagnostic still reaches the SQLSTATE (M90j keeps that reachable), while the served detail is the fixed sentence here — never the driver message, which on a pg error quotes the failing statement (X12-3 stays closed).

    The detail is also the answer to "what would a caller have been relying on before": a masked 500 carrying Internal Server Error and nothing else, which is not a behaviour any caller can depend on.

    import { SerializationConflictError } from '@setu-ts/database-plugin';
    try {
    await db.transaction(async (uow) => {
    const row = await uow.getRepository('Account').findById(id);
    await uow.getRepository('Account').update(id, { balance: row.balance - 10 });
    });
    } catch (err) {
    if (err instanceof SerializationConflictError) {
    // Retry: the transaction rolled back without applying.
    }
    }

    0.5.0

    Hierarchy

    • Error
      • SerializationConflictError
    Index
    • Creates the error. The message is the full diagnostic — safe to log, never to serve.

      Parameters

      • message: string

        The full diagnostic, safe to log

      • Optionaloptions: { cause?: unknown }

        The original driver error, preserved as cause

      Returns SerializationConflictError

    cause?: unknown
    message: string
    name: "SerializationConflictError" = 'SerializationConflictError'

    Discriminant for consumers that cannot use instanceof across realms.

    stack?: string
    stackTraceLimit: number

    The Error.stackTraceLimit property specifies the number of stack frames collected by a stack trace (whether generated by new Error().stack or Error.captureStackTrace(obj)).

    The default value is 10 but may be set to any valid JavaScript number. Changes will affect any stack trace captured after the value has been changed.

    If set to a non-number value, or set to a negative number, stack traces will not capture any frames.

    • Creates a .stack property on targetObject, which when accessed returns a string representing the location in the code at which Error.captureStackTrace() was called.

      const myObject = {};
      Error.captureStackTrace(myObject);
      myObject.stack; // Similar to `new Error().stack`

      The first line of the trace will be prefixed with ${myObject.name}: ${myObject.message}.

      The optional constructorOpt argument accepts a function. If given, all frames above constructorOpt, including constructorOpt, will be omitted from the generated stack trace.

      The constructorOpt argument is useful for hiding implementation details of error generation from the user. For instance:

      function a() {
      b();
      }

      function b() {
      c();
      }

      function c() {
      // Create an error without stack trace to avoid calculating the stack trace twice.
      const { stackTraceLimit } = Error;
      Error.stackTraceLimit = 0;
      const error = new Error();
      Error.stackTraceLimit = stackTraceLimit;

      // Capture the stack trace above function b
      Error.captureStackTrace(error, b); // Neither function c, nor b is included in the stack trace
      throw error;
      }

      a();

      Parameters

      • targetObject: object
      • OptionalconstructorOpt: Function

      Returns void

    • Parameters

      • err: Error
      • stackTraces: CallSite[]

      Returns any