openai/codex · error · MemoriesBackendError

all_within_lines.line_count must be a positive integer

Error message

all_within_lines.line_count must be a positive integer

What it means

Thrown by the memories search path (codex-rs/ext/memories/src/local/search.rs:29-34) when SearchMemoriesRequest.match_mode is SearchMatchMode::AllWithinLines { line_count: 0 }. The window is the maximum number of lines across which all queries must co-occur, so a zero-width window is rejected before any scanning. The schema (codex-rs/ext/memories/src/backend.rs:105-108) declares schemars range(min = 1) on line_count, matching the backend check.

Source

Thrown at codex-rs/ext/memories/src/backend.rs:159

    #[error("ad-hoc note '{filename}' already exists")]
    AdHocNoteAlreadyExists { filename: String },
    #[error("path '{path}' {reason}")]
    InvalidPath { path: String, reason: String },
    #[error("cursor '{cursor}' {reason}")]
    InvalidCursor { cursor: String, reason: String },
    #[error("path '{path}' was not found")]
    NotFound { path: String },
    #[error("line_offset must be a 1-indexed line number")]
    InvalidLineOffset,
    #[error("max_lines must be a positive integer")]
    InvalidMaxLines,
    #[error("line_offset exceeds file length")]
    LineOffsetExceedsFileLength,
    #[error("path '{path}' is not a file")]
    NotFile { path: String },
    #[error("queries must not be empty or contain empty strings")]
    EmptyQuery,
    #[error("all_within_lines.line_count must be a positive integer")]
    InvalidMatchWindow,
    #[error("I/O error while reading memories: {0}")]
    Io(#[from] std::io::Error),
}

impl MemoriesBackendError {
    pub fn invalid_filename(filename: impl Into<String>, reason: impl Into<String>) -> Self {
        Self::InvalidFilename {
            filename: filename.into(),
            reason: reason.into(),
        }
    }

    pub fn invalid_path(path: impl Into<String>, reason: impl Into<String>) -> Self {
        Self::InvalidPath {
            path: path.into(),
            reason: reason.into(),
        }

View on GitHub (pinned to 339751715c)

Solutions

  1. Use line_count >= 1 (a window of 1 behaves like AllOnSameLine).
  2. For 'queries may match anywhere in the file', use SearchMatchMode::Any instead of a zero window.
  3. Validate at your deserialization boundary and coerce 0 to 1 or reject it with a clearer message.

Example fix

// before
let mode = SearchMatchMode::AllWithinLines { line_count: window }; // window == 0

// after
let mode = match window {
    0 => SearchMatchMode::Any,
    1 => SearchMatchMode::AllOnSameLine,
    n => SearchMatchMode::AllWithinLines { line_count: n },
};
Defensive patterns

Strategy: validation

Validate before calling

// Rust - build a match mode that can never be a zero-width window
fn match_mode(window: usize) -> SearchMatchMode {
    match window {
        0 => SearchMatchMode::Any,
        1 => SearchMatchMode::AllOnSameLine,
        n => SearchMatchMode::AllWithinLines { line_count: n },
    }
}

Type guard

// Rust - predicate mirroring the backend check
fn match_mode_valid(mode: &SearchMatchMode) -> bool {
    !matches!(mode, SearchMatchMode::AllWithinLines { line_count: 0 })
}

Prevention

When it happens

Trigger: Constructing AllWithinLines with a usize that defaulted to 0; deserializing JSON {"type":"all_within_lines","line_count":0}; forwarding a user setting where 0 was supposed to disable the window.

Common situations: Default-constructed request structs; serde payloads from older or hand-written clients; porting a config whose 0 meant 'any distance' onto this API.

Related errors


AI-assisted analysis of openai/codex@339751715c (2026-08-25). Data as JSON: /api/errors/14593fef517b4d99. Report an issue: GitHub.