Fix state.yml race condition with PID-based file locking

[firecow]

• Add PID-based file lock to incrementPipelineIid to prevent concurrent processes from clobbering state.yml
• Stale locks from crashed/killed processes are auto-cleaned by checking PID liveness
• incrementPipelineIid returns the new IID directly, eliminating redundant getPipelineIid calls in handler
• Atomic state file writes via temp file + rename

[cubic-dev-ai]

1 issue found across 4 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src/state.ts">

<violation number="1" location="src/state.ts:53">
P1: Lock file with invalid/empty PID content (e.g., from a crash between `openSync` and `writeFileSync`) is never cleaned up, causing a 30-second timeout deadlock. When `parseInt` returns `NaN`, the `!isNaN(stalePid!)` check is `false`, so the cleanup branch is skipped entirely. An unrecognizable PID should be treated as stale.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[cubic-dev-ai]

1 issue found across 2 files (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src/pid-file-lock.ts">

<violation number="1" location="src/pid-file-lock.ts:25">
P1: Bug: The bare `catch` after `process.kill(pid, 0)` treats **all** errors as "process is dead", but `EPERM` means the process **is alive** (just owned by another user). Only `ESRCH` indicates a dead process. This can cause a live process's lock to be stolen.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
89.3% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud