ADORSYS-GIS / ADORSYS-GIS/lightbridge-governance
[Ticket]: split FileLock out of cache.rs — 719 lines after three baseline raises
- Linguagem predominante
- Rust
- Estrelas
- 1
- Forks
- 2
- Merge médio
- 13h 13min
- PRs com merge (30d)
- 110
Descrição
## Summary
`app/governance-auth/src/cache.rs` is now **719 lines** against a 200-line ceiling, having been baselined three times in a single branch (#228): 602 → 665 → 719. It is the largest file in the crate and wants splitting before the next feature touches it.
## Why it grew
Legitimately, each time — the lock ceiling for the hung-collector fix and the empty-lock grace both belong next to `FileLock`, and a second stale-lock implementation elsewhere would have been strictly worse. An independent review agreed the placement was right and that the raises were consistent with the gate's own remediation text and eight merged precedents.
That does not make three raises in one branch a good steady state.
## Suggested split
Extract `FileLock` (and its stale-lock reasoning, PID liveness, the empty-lock grace and the acquisition ceiling) into its own module. That is the cohesive unit: the session cache and the lock are separate concerns that happen to share a file.
## Related, separate
An observation from the same review, worth its own decision rather than folding in here: the LoC gate's stated rule is that grandfathered files "may be touched but **must not grow**", yet **every** commit that has touched one since the gate landed has raised its baseline — 8 of them, including one whose entire purpose was the raise and one that raised `otel.rs` by 166 lines. The clause has never bound anyone. Either it means something or it should be reworded.
## AI Usage Declaration
AI-assisted. Line counts and the precedent history are measured from the repository, not estimated. A human owns intent, verification and consequences.
Guia de contribuição
Avaliação
Esta issue ainda não foi avaliada.