thedotmack/claude-mem · warning

BullMQ re-enqueue failed (will reconcile on startup)

Error message

BullMQ re-enqueue failed (will reconcile on startup)

What it means

In the server jobs CLI, runJobsRetry re-publishes a failed job to BullMQ using its deterministic job id. If the republish call throws, the command logs this warning and continues — reconciliation on startup is expected to eventually re-enqueue the job, so the retry operation itself still succeeds.

Solutions

  1. Verify Redis is running and reachable (redis-cli ping) and restart it if needed.
  2. Rely on startup reconciliation — restart the claude-mem server so it reconciles and re-enqueues the job.
  3. Re-run the retry command once connectivity is restored.
  4. Check BullMQ queue configuration/naming if the queue was deliberately changed.

Example fix

// before: Redis down
redis-cli ping
// PONG missing -> start redis
redis-server --daemonize yes
// after: re-run
claude-mem server jobs retry <jobId>
Defensive patterns

Strategy: retry

Validate before calling

// Probe Redis before retrying jobs
import { execSync } from 'node:child_process';
execSync('redis-cli ping', { stdio: 'pipe' }); // non-zero exit if Redis is down

Type guard

function isRedisConnectionError(e: unknown): boolean {
  const msg = e instanceof Error ? e.message : String(e);
  return /ECONNREFUSED|Redis/i.test(msg);
}

Try / catch

try {
  await republishToBullmq(row.source_type, row.bullmq_job_id, newPayload);
} catch (error) {
  logger.warn('SYSTEM', 'BullMQ re-enqueue failed (will reconcile on startup)', {
    jobId: id,
    error: error instanceof Error ? error.message : String(error),
  });
  // startup reconciliation will re-enqueue; optionally retry with backoff
}

Prevention

When it happens

Trigger: Running `claude-mem server jobs retry <id>` when republishToBullmq throws — Redis/BullMQ unavailable, connection refused, queue missing, or the job id conflicts with an existing BullMQ job.

Common situations: Redis is down or restarted; network partition between CLI/server and Redis; BullMQ queue was flushed; job row exists in Postgres but was never published to BullMQ.

Understand the failure class

Background: ECONNREFUSED and "connection refused" / "could not connect to server" errors: what they mean and how to fix them — this error's family across 44 libraries.

Related errors

AI-assisted analysis of thedotmack/claude-mem@d8bc9755e7 (2026-09-17). Data as JSON: /api/errors/de47936df827d09a. Report an issue: GitHub.

Appendix: source

Thrown at src/npx-cli/commands/server-jobs.ts:287

    // Append lifecycle event row matching the audit chain shape.
    await pool.query(
      `INSERT INTO observation_generation_job_events (id, generation_job_id, event_type, status_after, attempt, details)
       VALUES (gen_random_uuid(), $1, 'queued', 'queued', $2, $3::jsonb)`,
      [id, row.attempts, JSON.stringify({ source: 'cli_operator_retry', retriedCount: newRetriedCount })],
    );

    await writeOperatorAudit(pool, lookup, 'generation_job.retried_by_operator', {
      previousStatus: lookup.status,
      currentStatus: row.status,
      retriedCount: newRetriedCount,
    });

    // Best-effort BullMQ re-publish using the deterministic id.
    if (row.bullmq_job_id) {
      try {
        await (testSeams.republishToBullmq ?? republishToBullmq)(row.source_type, row.bullmq_job_id, newPayload);
      } catch (error) {
        logger.warn('SYSTEM', 'BullMQ re-enqueue failed (will reconcile on startup)', {
          jobId: id,
          error: error instanceof Error ? error.message : String(error),
        });
      }
    }

    console.log(JSON.stringify({
      id: row.id,
      action: 'retry',
      outcome: 'requeued',
      retriedCount: newRetriedCount,
      status: row.status,
      attempts: row.attempts,
    }, null, 2));
  } finally {
    await releasePool();
  }
}

View on GitHub (pinned to d8bc9755e7)