Memory Leak in Fiber with Cockroachdb

A memory leak in a Fiber service that uses CockroachDB typically arises when application-level resources are retained unintentionally across requests, often due to how database client sessions, rows, or prepared statements are handled. Fiber is a fast, unopinionated web framework for Node.js, and CockroachDB is a distributed SQL database; the combination can expose leaks when developers do not consistently release database resources or when long-lived objects hold references to request-specific data.

One common pattern is failing to close rows or properly drain result sets after querying CockroachDB. For example, if you execute a query and iterate over rows without ensuring the result set is closed, the underlying client may retain buffers and connections, increasing memory usage over time. Another pattern is retaining request-scoped objects—such as middleware-attached user contexts or response locals—that indirectly reference database clients or transactions, preventing garbage collection from cleaning them up between requests.

Because middleBrick scans the unauthenticated attack surface and tests input validation and unsafe consumption patterns, it can surface findings related to inefficient resource handling that may contribute to memory growth. Although middleBrick does not directly identify memory leaks in heap profiles, it checks for unsafe consumption and input validation issues that can exacerbate retention problems when combined with CockroachDB interactions.

Real-world contributors include:

• Not closing Rows objects returned from db.Query().
• Holding references to sql.Tx or client sessions beyond the request lifecycle.
• Improper use of context cancellation, leading to abandoned queries that keep buffers alive.

These patterns can be uncovered indirectly by validating that endpoints properly handle errors and inputs, which is within the scope of the 12 parallel checks middleBrick runs, including Input Validation and Unsafe Consumption.

To prevent memory leaks when using CockroachDB with Fiber, ensure that every database interaction explicitly releases resources and uses context timeouts to avoid abandoned operations. Below are concrete, realistic examples demonstrating safe patterns.

1. Query and close rows properly

Always close Rows after iteration, even when errors occur. Use defer rows.Close() immediately after querying.

// Good: rows.Close() is deferred right after query
app.Get('/users', func(c *fiber.Ctx) error {
    rows, err := db.Query("SELECT id, name FROM users WHERE active = $1", true)
    if err != nil {
        return c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{"error": err.Error()})
    }
    defer rows.Close() // ensures resources are released

    var users []User
    for rows.Next() {
        var u User
        if err := rows.Scan(&u.ID, &u.Name); err != nil {
            return c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{"error": err.Error()})
        }
        users = append(users, u)
    }
    // Check error from iterating over rows
    if err := rows.Err(); err != nil {
        return c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{"error": err.Error()})
    }
    return c.JSON(users)
})

2. Use transactions with explicit commit/rollback and early release

When using transactions, ensure they are committed or rolled back and that the transaction handle is not retained beyond the request scope.

app.Post('/transfer', func(c *fiber.Ctx) error {
    tx, err := db.Begin() // starts a CockroachDB transaction
    if err != nil {
        return c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{"error": err.Error()})
    }
    // Ensure rollback if commit is not called; do not defer tx.Commit() unconditionally
    defer func() {
        if p := recover(); p != nil {
            tx.Rollback()
            panic(p)
        } else if err != nil {
            tx.Rollback()
        } else {
            err = tx.Commit()
        }
    }()

    var from, to int64
    if err := c.BodyParser(&struct{ From, To int64 }{from, to}); err != nil {
        return c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": err.Error()})
    }

    // Execute queries using tx, checking errors to decide rollback
    _, err = tx.Exec("UPDATE accounts SET balance = balance - $1 WHERE id = $2", from, from)
    if err != nil {
        return nil // rollback handled by deferred func
    }
    _, err = tx.Exec("UPDATE accounts SET balance = balance + $1 WHERE id = $2", to, to)
    if err != nil {
        return nil
    }
    return nil
})

3. Use context with timeouts to prevent long-lived queries

Pass a context with a timeout or deadline to database operations to ensure they are canceled if they take too long, reducing the chance of lingering resources.

ctx, cancel := context.WithTimeout(context.Background(), 8*time.Second)
defer cancel()

app.Get('/search', func(c *fiber.Ctx) error {
    query := c.Query("q")
    rows, err := db.QueryContext(ctx, "SELECT id, title FROM documents WHERE content @@ plainto_tsquery($1)", query)
    if err != nil {
        return c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{"error": err.Error()})
    }
    defer rows.Close()

    var results []Document
    for rows.Next() {
        var d Document
        if err := rows.Scan(&d.ID, &d.Title); err != nil {
            return c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{"error": err.Error()})
        }
        results = append(results, d)
    }
    if err := rows.Err(); err != nil {
        return c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{"error": err.Error()})
    }
    return c.JSON(results)
})

By consistently closing rows, managing transaction lifetimes, and using timeboxed contexts, you reduce the risk of memory retention when Fiber interacts with CockroachDB. These patterns align with the checks performed by middleBrick, such as Input Validation and Unsafe Consumption, which help identify endpoints that may contribute to resource leakage indirectly.