Summary
Follow-up to #280: add a stable per-instance identifier to contest-sync logs so activity from multiple application replicas can be correlated in a shared log stream.
PR #280 made the contest sync execution-safe across instances using a MongoDB-backed distributed lock. Its logs still use a static prefix such as [Contest Sync], however. In a multi-replica deployment, this does not identify which process acquired the lock, completed a sync, skipped because another replica owns the lease, or emitted an error.
Observability gap
When multiple instances run concurrently—such as PM2 cluster workers, Render/Railway replicas, Kubernetes pods, or Docker Swarm tasks—their stdout/stderr is commonly aggregated. Without an instance identifier, log lines are indistinguishable across processes.
For example, an operator can see:
[Contest Sync] Synced 24 Codeforces contest(s).[Contest Sync] Skipped - another instance holds the lock.
but cannot determine which replica performed the sync and which replica skipped. This prevents reconstructing ownership and execution flow during an incident.
Production impact
The lack of instance-level context makes the following scenarios unnecessarily difficult to debug:
- Investigating whether the distributed lock is consistently selecting one executor across replicas.
- Identifying the replica that produced sync failures, slow requests, or database errors.
- Correlating application logs with a specific Kubernetes pod, container, PM2 worker, host, or platform instance.
- Diagnosing restart loops or deployments where a newly started replica repeatedly attempts the immediate startup sync.
- Determining whether unexpected duplicate work came from the same process or separate replicas.
The lock remains correct, but incident response and post-incident diagnosis are impaired as horizontal scaling increases.
Affected areas
server/jobs/contestSync.js — contest-sync success, skip, lock-acquisition-failure, and error logs.- Server configuration/environment handling — source or derive a stable identifier for the running process/replica.
Required changes
- Add an instance identifier to every contest-sync log line.
- Prefer a configurable environment value when the deployment platform provides one; otherwise use a safe generated process-local fallback established at startup.
- Use a consistent log format for successful runs, lock contention/skips, acquisition failures, release failures, and sync errors.
- Ensure the identifier is safe to expose in logs and does not include secrets.
- Keep the locking behavior and existing sync semantics unchanged.
Acceptance criteria
References
Summary
Follow-up to #280: add a stable per-instance identifier to contest-sync logs so activity from multiple application replicas can be correlated in a shared log stream.
PR #280 made the contest sync execution-safe across instances using a MongoDB-backed distributed lock. Its logs still use a static prefix such as
[Contest Sync], however. In a multi-replica deployment, this does not identify which process acquired the lock, completed a sync, skipped because another replica owns the lease, or emitted an error.Observability gap
When multiple instances run concurrently—such as PM2 cluster workers, Render/Railway replicas, Kubernetes pods, or Docker Swarm tasks—their stdout/stderr is commonly aggregated. Without an instance identifier, log lines are indistinguishable across processes.
For example, an operator can see:
[Contest Sync] Synced 24 Codeforces contest(s).[Contest Sync] Skipped - another instance holds the lock.but cannot determine which replica performed the sync and which replica skipped. This prevents reconstructing ownership and execution flow during an incident.
Production impact
The lack of instance-level context makes the following scenarios unnecessarily difficult to debug:
The lock remains correct, but incident response and post-incident diagnosis are impaired as horizontal scaling increases.
Affected areas
server/jobs/contestSync.js— contest-sync success, skip, lock-acquisition-failure, and error logs.Required changes
Acceptance criteria
server/jobs/contestSync.jsincludes a non-empty instance identifier.References