Release 0.197.13: Mock Room Exclusion in Controller Health Monitoring

(Updated: )
Release Notes
, , ,

Introduction

Version 0.197.13 is a focused maintenance release that addresses a monitoring system refinement. This release documents and formalizes the exclusion of test/mock rooms from controller health monitoring alerts, preventing false positives in production monitoring workflows.

Key Features

Mock Room Exclusion in Controller Health Monitoring

The primary enhancement in this release is the documentation and formalization of mock room exclusion from controller downgrade alerts:

  • Room E54N39 is now explicitly excluded from controller health monitoring
  • Prevents false alerts when test snapshots containing mock data are processed
  • Maintains monitoring accuracy by filtering out non-production rooms

Technical Details

Implementation and Design Rationale

The controller health monitoring system (check-controller-health.ts) analyzes bot snapshots to detect controller downgrade risks across all claimed rooms. However, when running integration tests with screeps-server-mockup, test data containing the mock room E54N39 can inadvertently be included in monitoring artifacts.

Problem: Test snapshots with mock rooms would trigger spurious production alerts, creating noise in the monitoring system and potentially masking genuine production issues.

Solution: An explicit exclusion list was documented in packages/docs/source/docs/automation/monitoring-telemetry.md, clarifying that room E54N39 is filtered out during health checks:

1
const MOCK_ROOM_NAME = "E54N39";

Room Validation Logic

The controller health monitoring now employs a two-stage validation process:

  1. Pattern Validation: Room names must match the Screeps coordinate pattern ^[EW]\d+[NS]\d+$

    • Filters out metadata entries (e.g., “count”)
    • Rejects malformed room names

  2. Explicit Exclusion: Mock rooms are explicitly filtered

    • Currently excludes E54N39 (test/mockup room)
    • Extensible design allows adding future exclusions as needed

This approach ensures only valid production rooms are monitored while test infrastructure remains isolated from production alerting.

Documentation Structure

The updated monitoring-telemetry.md documentation now includes:

  • Room Exclusions Table: Clear listing of excluded rooms with justification
  • Configuration Reference: Code snippet showing where exclusions are defined
  • Room Validation Section: Explanation of filtering logic and regex patterns

Impact

Monitoring Reliability

This release improves the signal-to-noise ratio in the autonomous monitoring system:

  • Eliminates False Positives: Test data no longer generates production alerts
  • Improves Alert Accuracy: Monitoring agents can trust that controller downgrade warnings reflect actual production risks
  • Reduces Operational Overhead: No manual filtering needed to distinguish real alerts from test artifacts

Development Workflow

The formalized exclusion pattern establishes a precedent for handling other non-production rooms:

  • Clear documentation makes the system behavior transparent
  • Extensible exclusion list supports future test environments
  • Maintains separation between test and production monitoring data

Strategic Alignment

This change supports the repository’s autonomous monitoring goals (Issue #239) by ensuring high-quality telemetry:

  • Monitoring agents receive clean, production-only data
  • Strategic analysis workflows aren’t skewed by test artifacts
  • Controller downgrade detection remains reliable for actual game rooms

This release modifies one documentation file:

  • packages/docs/source/docs/automation/monitoring-telemetry.md - Added mock room exclusion documentation and room validation logic

No runtime code changes were required, as the exclusion logic was already implemented in check-controller-health.ts. This release formalizes and documents existing behavior.

What’s Next

While this release focuses on documentation, it lays groundwork for future monitoring enhancements:

  • Extensible Exclusion System: Additional test rooms can be easily added to the exclusion list
  • Multi-Environment Support: Pattern established for handling dev/staging/production room segregation
  • Monitoring Quality Improvements: Clean telemetry enables more sophisticated anomaly detection

Future releases will continue refining the autonomous monitoring system, with upcoming focus areas including enhanced strategic analysis and proactive issue detection.

Release Information:

  • Version: 0.197.13
  • Release Date: 2025-11-30
  • Commit: c920ba071a890264eaeedce1c7f3a079647e4dc4
  • Pull Request: #1597
  • Category: Documentation & Operations

Contributors:

  • Copilot (via copilot-swe-agent[bot])
  • @ralphschuler