cayleygraph/cayley · error

error updating node: %v

Error message

error updating node: %v

What it means

This error is returned by QuadStore.updateNodeBy when the underlying NoSQL document store (qs.db) fails to run an Update/Upsert/Inc operation on the nodes collection while applying a delta. It wraps the driver-level error from the Update(...).Do(ctx) call. The node's fldSize counter could not be incremented (or the node upserted), so the ApplyDeltas transaction for this node fails.

Source

Thrown at graph/nosql/quadstore.go:249

		return ""
	}
	h := quad.HashOf(s)
	return base64.StdEncoding.EncodeToString(h)
}

func (qs *QuadStore) nameToKey(name quad.Value) nosql.Key {
	node := qs.hashOf(name)
	return node.key()
}

func (qs *QuadStore) updateNodeBy(ctx context.Context, key nosql.Key, name quad.Value, inc int) error {
	if inc == 0 {
		return nil
	}
	d := toDocumentValue(&qs.opt, name)
	err := qs.db.Update(colNodes, key).Upsert(d).Inc(fldSize, inc).Do(ctx)
	if err != nil {
		return fmt.Errorf("error updating node: %v", err)
	}
	return nil
}

func (qs *QuadStore) cleanupNodes(ctx context.Context, keys []nosql.Key) error {
	err := qs.db.Delete(colNodes).Keys(keys...).WithFields(nosql.FieldFilter{
		Path:   []string{fldSize},
		Filter: nosql.Equal,
		Value:  nosql.Int(0),
	}).Do(ctx)
	if err != nil {
		err = fmt.Errorf("error cleaning up nodes: %v", err)
	}
	return err
}

func (qs *QuadStore) updateQuad(ctx context.Context, q quad.Quad, proc graph.Procedure) error {
	var setname string

View on GitHub (pinned to 81dcd7d73e)

Solutions

  1. Inspect the wrapped %v cause (the driver error) — fix the underlying database connectivity or error first.
  2. Verify the NoSQL connection URI/config in the Cayley spec file and test connectivity with a simple read before writing.
  3. Retry ApplyDeltas; nosql updates are per-key upserts so re-applying the same delta batch after failure is generally safe for idempotent deltas.
  4. Check ctx cancellation/timeouts — increase timeout or split the delta batch into smaller ApplyDeltas calls.
  5. Upgrade/verify the specific NoSQL driver version matches what your Cayley build expects.

Example fix

// before
err := qs.db.Update(colNodes, key).Upsert(d).Inc(fldSize, inc).Do(ctx)
// after
ctx, cancel := context.WithTimeout(ctx, 30*time.Second)
defer cancel()
if err := qs.db.Update(colNodes, key).Upsert(d).Inc(fldSize, inc).Do(ctx); err != nil {
    return fmt.Errorf("error updating node: %w", err)
}
Defensive patterns

Strategy: try-catch

Validate before calling

// before ApplyDeltas, ping the store
if _, err := store.Quads(ctx); err != nil {
    return fmt.Errorf("store unreachable, skipping ApplyDeltas: %w", err)
}
if err := ctx.Err(); err != nil {
    return err
}

Try / catch

if err := store.ApplyDeltas(ctx, deltas, true); err != nil {
    var wrapped interface{ Unwrap() error }
    if errors.As(err, &wrapped) {
        log.Printf("node update failed, cause: %v", errors.Unwrap(err))
    }
    // retry idempotent delta batch with backoff
}

Prevention

When it happens

Trigger: Calling ApplyDeltas with a delta on a node when the backing NoSQL database (e.g. MongoDB, Bolt) is unavailable, the ctx is cancelled/timed out, the key/collection is corrupted or locked, or the driver rejects the update (e.g. document too large, connection dropped mid-write).

Common situations: MongoDB connection pool exhaustion or replica stepdown during bulk quad writes; context deadline exceeded during large ApplyDeltas batches; misconfigured NoSQL URI so the store is unreachable; concurrent writers hitting a locked Bolt/single-writer database.

Related errors


AI-assisted analysis of cayleygraph/cayley@81dcd7d73e (2026-09-06). Data as JSON: /api/errors/3a7ab4fa34796c54. Report an issue: GitHub.