overleaf/overleaf · error · TooLongError

resulting string would be too long

Error message

resulting string would be too long

What it means

After applying, if the resulting string exceeds TextOperation.MAX_STRING_LENGTH, the library throws TooLongError instead of materializing an oversized document in memory. This guards against runaway insertions (often from bugs or malicious clients) exhausting memory or breaking downstream persistence limits.

Source

Thrown at libraries/overleaf-editor-core/lib/operation/text_operation.js:334

        result += op.insertion
      } else if (op instanceof RemoveOp) {
        file.comments.applyDelete(new Range(result.length, op.length))
        inputCursor += op.length
      } else {
        throw new UnprocessableError('Unknown ScanOp type during apply')
      }
    }

    if (inputCursor !== str.length) {
      throw new TextOperation.ApplyError(
        "The operation didn't operate on the whole string.",
        operation,
        str
      )
    }

    if (result.length > TextOperation.MAX_STRING_LENGTH) {
      throw new TextOperation.TooLongError(operation, result.length)
    }

    file.trackedChanges.applyTextOperation(this)

    file.content = result
  }

  /**
   * @inheritdoc
   * @param {number} length of the original string; non-negative
   * @return {number} length of the new string; non-negative
   */
  applyToLength(length) {
    const operation = this
    if (length !== operation.baseLength) {
      throw new TextOperation.ApplyError(
        "The operation's base length must be equal to the string's length.",
        operation,

View on GitHub (pinned to 28ad3b03b7)

Solutions

1. Check TextOperation.MAX_STRING_LENGTH and the current content length before building/applying big insertions
2. Split the change into smaller operations, or increase MAX_STRING_LENGTH if your storage backend truly supports larger files
3. Reject oversized inserts at the API/websocket layer with a clear 413-style error to the client
4. Detect runaway insertion loops client-side (cap insert size per op batch)

Example fix

// before
file.apply(new TextOperation().insert(hugeString)) // throws TooLongError
// after
if (file.getContent().length + hugeString.length > TextOperation.MAX_STRING_LENGTH) {
  throw new Error('document too large')
}
file.apply(new TextOperation().insert(hugeString))

function fitsLengthLimit(file, insertText) {
  return file.getContent().length + insertText.length <= TextOperation.MAX_STRING_LENGTH
}
// guard: if (!fitsLengthLimit(file, text)) reject or split the insert

try {
  file.apply(op)
} catch (err) {
  if (err.name === 'TooLongError') {
    logger.warn({ size: err.size }, 'resulting document too long')
    throw new ClientError(413, 'document exceeds maximum length')
  }
  throw err
}

When it happens

Trigger: file.apply(op) where result.length > TextOperation.MAX_STRING_LENGTH — e.g. huge paste inserts, repeated large appends, or a client submitting ops that grow the file beyond the configured cap.

Common situations: Users pasting very large documents; a client bug in a loop that keeps inserting; attackers inflating documents; deployments that lowered MAX_STRING_LENGTH below existing document sizes so valid-looking ops now fail.

Related errors

• The operation's base length must be equal to the string's le
• Operation can't retain more chars than are left in the strin
• Unknown ScanOp type during apply
• The operation didn't operate on the whole string.
• blocking doc update: doc is too large

AI-assisted analysis of overleaf/overleaf@28ad3b03b7 (2026-09-03). Data as JSON: /api/errors/fbf4e7965ddff23b. Report an issue: GitHub.