OptionalcauseOptionalstackStaticstackThe 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.
StaticcaptureCreates 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();
OptionalconstructorOpt: FunctionStaticprepare
Raised when a position-mutating operation waited too long for another transaction to release a sort scope.
Every position-mutating path — a save, a destroy, an undestroy, a locked batch,
Dream.resort— computes its positions under an exclusive advisory lock on the sort scope, held until the transaction that took it ends. A writer that finds the scope already locked waits, and that wait is bounded: Dream applies alock_timeout(5 seconds by default, set through thesortableScopeLockTimeoutDreamApp option) to the acquisition statement alone, and restores whateverlock_timeoutwas in effect afterward, so the transaction's other lock waits — row locks taken bylock: true, foreign key checks — are left exactly as the application configured them.This is a retryable condition: the operation touched nothing, and the holder it was waiting for is a transaction that will end. What has to be retried depends on who owns the transaction. When Dream opened it — a plain
save(),destroy(),undestroy()orresort()— only that call was rolled back, and retrying the call is the whole response. Inside a transaction the caller owns, the failed statement aborts the entire transaction: nothing further can run on it, and the caller has to retry the transaction as a whole rather than the sortable operation inside it.Hitting this bound routinely is a signal rather than a transient: it means one sort scope is being written by more concurrent writers than it can serialize, or that something slow is running inside a transaction that holds the scope — on a destroy or an undestroy, that includes your own
afterDestroyandafterUpdatehooks, which run inside the lock window.