Skip to content

🧠 (SCS/EEE) Non-Exhaustive Directory Polling during Log Rollover #36

@OppaAI

Description

@OppaAI

⚠️ Issue: Archival Bypass in Multi-Rotation Events

The doRollover implementation currently utilizes a hardcoded target identifier (.1). In high-throughput logging scenarios where the rotation frequency exceeds the worker thread's processing velocity, files incremented beyond the .1 suffix (e.g., .2, .3) are orphaned. These archives remain in a raw state, bypassing the background compression queue entirely.

🎯 Location:

robot/scs/eee.py -> GzipRotatingFileHandler.doRollover()

🦠 Symptoms:

  • Unbounded Disk Consumption: Raw log files persist on the filesystem, bypassing the 10:1 compression ratio expected from the ACV.
  • Metadata Decay: The sequential relationship between logs is preserved in name but broken in state (mixture of .gz and raw text).
  • Processing Dead-Zones: Archives that move past the .1 index during a "Queue Full" event are never re-evaluated for compression until a class-level re-initialization.

🩺 Diagnosis:

The logic relies on a Point-in-Time Assumption. It assumes that the only file requiring compression is the one most recently rotated. This creates a race condition where any lag in the consumer thread results in permanent data-processing skips for specific file indices.

💡 Proposal:

Directory-Wide Filter Pattern Modify doRollover to perform a non-recursive glob of the baseFilename directory. The handler should identify all files matching the rotation pattern that do not possess a .gz extension and enqueue them for processing.

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Projects

Status

Todo

Relationships

None yet

Development

No branches or pull requests

Issue actions