test[oz-retainer-07-m-01]: cover overlapping liveness targets

[md0x]

Audit finding

OpenZeppelin Retainer 07 identified the following issue:

M-01 — Incorrect Liveness Range Validation in OOReporter

• Severity: Medium
• Status: Open

registerRequest accepts ranges that overlap the current Managed OO bounds, so a caller selecting an endpoint outside those bounds cannot initialize the request.

References: OpenZeppelin audit findings · FRO-97 · audited scope tag

Resolution

This PR is stacked on #53, which makes minimumLiveness the hard onchain floor and maximumLiveness an offchain target rather than a runtime ceiling.

• Preserve the registration overlap predicate so the target range has a valid normal-path choice under the current Managed OO configuration.
• Continue relying on Managed OO to enforce its current minimum and exclusive technical maximum at initialization.
• Cover initialization inside the intersection of a partially overlapping target range and the current Managed OO bounds.
• Retain fix[oz-retainer-07-m-02]: remove OOReporter runtime liveness cap #53's coverage for initialization and manual recovery above a stale target maximum after configuration drift.

Validation

• cd pm-v2-oo-reporter && forge fmt --check
• cd pm-v2-oo-reporter && forge test --match-path test/OOReporter.t.sol — 42 tests passed
• git diff --check

[linear]

FRO-97

[Reinis-FRP]

PR #53 intentionally makes maximumLiveness an off-chain target rather than a runtime ceiling, allowing the oracle initializer to exceed it when MOOv2 configuration drift would otherwise brick the request. Under that model, registration only needs to establish that the target range intersects MOOv2’s current valid range.

The previous predicate does exactly that: minimumLiveness < MAXIMUM_CUSTOM_LIVENESS ensures the hard requester floor does not make initialization impossible, while maximumLiveness >= oracleMinimumLiveness ensures the soft target range has a normal-path valid choice at registration. The new containment checks unnecessarily reject partially overlapping ranges and contradict the companion PR’s recovery semantics.

Please retain the overlap predicate and test both paths: initialization within the target intersection under unchanged configuration, and initialization above the soft maximumLiveness after minimumDisputeWindow drifts past it.

[md0x]

Agreed — with #53, maximumLiveness is a soft offchain target, so registration should require overlap rather than full containment. I’ve stacked this PR on #53, restored the overlap semantics, and reduced #54 to focused coverage for initialization inside a partially overlapping target range. The stacked #53 tests also cover initialization and manual recovery above a stale target maximum after minimumDisputeWindow drifts. forge fmt --check and the 42-test OOReporter suite pass.

[chrismaree]

Reviewed against FRO-97 and the #53/FRO-107 semantic contract. The focused overlap test matches the hard-floor/soft-target model, while Managed OO continues enforcing live protocol bounds. The prior thread is outdated and substantively addressed.

Merge-order note: land #53 first, then retarget #54 to unaudited-pm-v2-oo-reporter before merging it.

---

Sent from Chris Codex Agent 🤖