abhigyanpatwari/GitNexus · warning
⚠️ Schema creation warning: ${msg.slice(0, 120)}
Error message
⚠️ Schema creation warning: ${msg.slice(0, 120)} What it means
During LadybugDB schema creation (ensureLbugInitialized DDL), a statement failed with an error whose message does not contain 'already exists' and is not a busy or read-only error. The adapter logs the first 120 chars and continues with a partially created schema — later queries against missing tables may fail. Note the adjacent stricter path: if the error is classified as WAL corruption, the DB is closed and a hard error with WAL_RECOVERY_SUGGESTION is thrown instead.
Source
Thrown at gitnexus/src/core/lbug/lbug-adapter.ts:704
// on the next operation via withLbugDb's retry. Logging it here
// would just be noise in CI.
//
// WAL corruption: the first DDL write after DB open triggers WAL
// replay — if the WAL file was left in a corrupt state by an
// interrupted previous run, the native engine throws here. Rather
// than logging a WARN and continuing in a broken state, close the
// DB cleanly and surface an actionable error so the caller (serve,
// MCP, analyze) can exit with a clear recovery message.
if (isWalCorruptionError(err)) {
await safeClose();
resetOpenConnectionState();
throw new Error(
`LadybugDB WAL corruption detected at ${dbPath}. ${WAL_RECOVERY_SUGGESTION}\n` +
` Original error: ${msg.slice(0, 200)}`,
);
}
if (!msg.includes('already exists') && !isDbBusyError(err) && !isReadOnlyDbError(err)) {
logger.warn(`⚠️ Schema creation warning: ${msg.slice(0, 120)}`);
}
}
}
return null;
};
export const initLbug = async (dbPath: string) => {
return runWithSessionLock(() => ensureLbugInitialized(dbPath));
};
/**
* Execute multiple queries against one repo DB atomically.
* While the callback runs, no other request can switch the active DB.
*
* Automatically retries up to DB_LOCK_RETRY_ATTEMPTS times when the
* database is busy (e.g. `gitnexus analyze` holds the write lock).
* Each retry waits DB_LOCK_RETRY_DELAY_MS * attempt milliseconds.View on GitHub (pinned to 0d1aed942f)
Solutions
- Delete (or move aside) the DB directory and re-run analyze to recreate the schema from scratch: `rm -rf .gitnexus` then `gitnexus analyze`.
- Check disk space and write permissions on the .gitnexus directory.
- Reinstall/upgrade gitnexus so the DDL matches the vendored LadybugDB build (`npm install gitnexus@latest`), including the postinstall grammar/native materialization step.
- If the message hints at WAL corruption, follow the WAL_RECOVERY_SUGGESTION the harder path prints (remove WAL sidecars / rebuild DB).
Example fix
# before: schema creation warning, subsequent queries fail on missing tables rm -rf .gitnexus && npx gitnexus@latest analyze # after: fresh schema, matched to current engine
Defensive patterns
Strategy: validation
Validate before calling
// Before init: disk headroom and a clean slate when schema is suspect
import { statfs, rm } from 'node:fs/promises';
const { bavail, bsize } = await statfs(path.dirname(dbPath));
if (bavail * bsize < 500 * 1024 * 1024) throw new Error('insufficient disk for schema creation');
if (schemaVersionUnknown) await rm(path.dirname(dbPath), { recursive: true, force: true }); Try / catch
try {
await initLbug(dbPath);
} catch (err) {
// WAL-corruption errors from init carry WAL_RECOVERY_SUGGESTION — surface it verbatim
if (/WAL corruption|recovery/i.test(String(err?.message))) console.error(err.message);
throw err;
} Prevention
- Recreate the DB from scratch after major gitnexus upgrades instead of reusing old DB files.
- Monitor free space on the DB volume before long analyze runs.
- Pin one gitnexus version per repo to keep DDL and engine in lockstep.
When it happens
Trigger: initLbug/ensureLbugInitialized runs CREATE TABLE/INDEX statements and one fails for a non-idempotent reason: disk full, native extension version mismatch (DDL uses syntax the bundled LadybugDB does not support), permission errors on the DB directory, or mild corruption. Only the message is captured, so the underlying errno/engine code lives in the log context.
Common situations: Upgrading gitnexus where new DDL targets a changed LadybugDB feature set while an old DB/state lingers; full disks; DB directories created by a different user; partial native module installs after a failed `npm install` (source-build fallback).
Related errors
- [lbug-load] node COPY also failed while relationship emit wa
- parsedfile-cache: could not reset durable chunk generation;
- LadybugDB not initialized for repo "${repoId}". Call initLbu
- withRetry: maxAttempts must be >= 1, got ${opts.maxAttempts}
- [understand-quickly] expected id of the form "owner/repo", g
AI-assisted analysis of abhigyanpatwari/GitNexus@0d1aed942f (2026-08-20).
Data as JSON: /api/errors/1a74581fd8eb29a8.
Report an issue: GitHub.