What causes "Value log GC request rejected" in dgraph-io/badger?

Ensure db.Close() happens only after all GC calls have finished

ErrRejected

ErrRejected

Error message

Value log GC request rejected

What it means

ErrRejected is returned when a value log GC request cannot be accepted because another GC is already running, or because DB.Close has already been called. Badger serializes value log GC internally and refuses concurrent or post-close requests. Defined in errors.go as a sentinel error.

Source

Thrown at errors.go:60

	// ErrInvalidKey is returned if the key has a special !badger! prefix,
	// reserved for internal usage.
	ErrInvalidKey = stderrors.New("Key is using a reserved !badger! prefix")

	// ErrBannedKey is returned if the read/write key belongs to any banned namespace.
	ErrBannedKey = stderrors.New("Key is using the banned prefix")

	// ErrThresholdZero is returned if threshold is set to zero, and value log GC is called.
	// In such a case, GC can't be run.
	ErrThresholdZero = stderrors.New(
		"Value log GC can't run because threshold is set to zero")

	// ErrNoRewrite is returned if a call for value log GC doesn't result in a log file rewrite.
	ErrNoRewrite = stderrors.New(
		"Value log GC attempt didn't result in any cleanup")

	// ErrRejected is returned if a value log GC is called either while another GC is running, or
	// after DB::Close has been called.
	ErrRejected = stderrors.New("Value log GC request rejected")

	// ErrInvalidRequest is returned if the user request is invalid.
	ErrInvalidRequest = stderrors.New("Invalid request")

	// ErrManagedTxn is returned if the user tries to use an API which isn't
	// allowed due to external management of transactions, when using ManagedDB.
	ErrManagedTxn = stderrors.New(
		"Invalid API request. Not allowed to perform this action using ManagedDB")

	// ErrNamespaceMode is returned if the user tries to use an API which is allowed only when
	// NamespaceOffset is non-negative.
	ErrNamespaceMode = stderrors.New(
		"Invalid API request. Not allowed to perform this action when NamespaceMode is not set.")

	// ErrInvalidDump if a data dump made previously cannot be loaded into the database.
	ErrInvalidDump = stderrors.New("Data dump cannot be read")

	// ErrZeroBandwidth is returned if the user passes in zero bandwidth for sequence.

View on GitHub (pinned to 2a001d466f)

Solutions

Ensure db.Close() happens only after all GC calls have finished
Serialize GC calls with a mutex or single dedicated GC goroutine
Check that no background job outlives the DB handle before closing
Retry later if the rejection was due to a concurrent GC

Example fix

// before
err := db.RunValueLogGC(0.5)
// after
if err := db.RunValueLogGC(0.5); err != nil && errors.Is(err, ErrRejected) {
	// GC already running or DB closed; skip
	return nil
}

Defensive patterns

Strategy: retry

Validate before calling

if db.IsClosed() { return nil } // guard via your own lifecycle state before GC

Type guard

func isRejected(err error) bool { return errors.Is(err, ErrRejected) }

Try / catch

err := gcMu.RunValueLogGC(0.5)
if errors.Is(err, ErrRejected) {
	// retry later or skip; GC busy or DB closed
}

Prevention

Single-flight GC: one goroutine owns RunValueLogGC calls
Never call GC after Close; integrate GC into the DB lifecycle
Use a mutex around GC triggers from multiple components

When it happens

Trigger: Calling db.RunValueLogGC while a previous GC is still in progress; calling db.RunValueLogGC after db.Close() (as in value_test.go:765).

Common situations: Multiple goroutines or a cron job triggering GC concurrently; an application shutdown path that still invokes GC after the DB was closed; subscription/callback code firing GC late in the lifecycle.

Related errors

AI-assisted analysis of dgraph-io/badger@2a001d466f (2026-09-05). Data as JSON: /api/errors/3aa221aa428b4b5a. Report an issue: GitHub.