🧠 (SCS/EEE) Recursive Suffix Appendage in Archive Naming Logic

[OppaAI]

⚠️ Issue: Idempotency Failure in Filename Formatting

The _apply_archive_tag method is non-idempotent. When the namer is invoked on a file that has already undergone 3-digit padding (e.g., log.001), the logic treats the existing suffix as a new integer and re-applies the formatting. This results in an infinite expansion of the filename string.

🎯 Location:

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

🦠 Symptoms:

• Path Length Violation: Filenames grow exponentially (log.001.001.001...), eventually exceeding the OS MAX_PATH limit and throwing FileNotFoundError.
• Regex Failure: Downstream compression workers cannot parse the file index, as the standard rsplit('.', 1) logic fails to capture the intended file identity.
• Resource Leak: Continuous string manipulation and file renaming operations consume unnecessary CPU cycles.

🩺 Diagnosis:

The system suffers from a State-Agnostic Mutation. The formatting logic does not validate the current state of the string (suffix length or extension) before applying the transformation, leading to recursive application of the 03d format string.

💡 Proposal:

Suffix Length Validation Guard Implement a conditional check to verify the length of the final numeric segment. If the segment is already 3 digits or if the .gz extension is present, the method must return the input string unmodified to ensure idempotency.