#31: [bug] Accept up to 256 application periods per PRIM disruption · anthodev/lapin-fute

Impact Version (SemVer)

PATCH

Description

A valid PRIM incident containing more than 128 application periods causes the companion to reject the entire regional traffic response. Favorites can consequently report unknown traffic even when their lines are unrelated to the offending incident. Raise the per-disruption limit to 256 while preserving validation and response-size protections.

Steps to Reproduce

Provide a valid disruptions bulk response containing an incident with 130 distinct, valid application periods.
Request traffic for a different valid line through the production PRIM client.
With the previous 128-period limit, normalization rejects the entire response, the client returns UNAVAILABLE / INVALID_RESPONSE, and the overview reports UNKNOWN.

The authorized live capture received on 2026-10-06 at 21:06:49 UTC returned HTTP 200 with 853 incidents and 717 lines. A bus 1205 works notice, linked to line:IDFM:C01475, contained 130 application periods and triggered this rejection.

Current Behavior

The previous implementation bounded each incident at 128 periods in packages/companion/src/prim-traffic.js. One over-limit incident invalidated all regional traffic data. A local, uncommitted correction now raises this limit to 256; it has not been deployed.

Expected Behavior

Valid incidents with up to 256 application periods are accepted. Their active periods remain correctly evaluated, and traffic for unrelated lines stays available. An incident with 257 periods still causes INVALID_RESPONSE; malformed dates and other invalid fields remain rejected.

Acceptance Criteria

Accept 256 valid, distinct periods and recognize an incident whose last period is the active one.
Preserve the normalized incident title and message and the unaffected line's normal status.
Reject 257 periods rather than silently truncating or dropping an incident.
A production-client replay with a 256-period incident on another line returns AVAILABLE / NORMAL for the requested unaffected line.
Offline production-client smoke accepts 130 and 256 periods and rejects 257.
Update README and the categorized Unreleased changelog entry.
Complete the full repository test suite once the missing local dependencies are available.

Affected Endpoints/Routes

Upstream: GET https://prim.iledefrance-mobilites.fr/marketplace/disruptions_bulk/disruptions/v2.
Companion: normalizePrimTrafficResponse, createPrimClient, and overview traffic summaries. No backend or wire-contract change.

Tests

Type	Coverage
Node unit tests	Admission at 256 periods, evaluation of the last active period, preserved details, rejection at 257
Node client integration	Long notice on an unrelated line does not invalidate the requested line's traffic
Offline runtime smoke	Real production client with recorded synthetic HTTP responses at 130, 256, and 257 periods

Existing test file: packages/companion/test/prim-traffic-empty-periods.test.js. All six tests in that file passed. npm run measure:radio passed its host-modeled gate. npm test was attempted but failed on missing csv-parse and yauzl imports in other suites. No dependencies were installed.

Constraints

Change only the per-disruption period limit from 128 to 256; retain the 2 MiB bulk-response cap and all existing date and payload validation.
Preserve whole-response rejection above the new bound; do not add partial tolerance, retries, polling, or bus-specific exceptions.
No watch memory increase, D2 changes, catalog rebuild, or version bump.
No additional authenticated PRIM requests; use deterministic offline data. Never read or expose .env or credentials.

Technical Context

Local changes are in packages/companion/src/prim-traffic.js, packages/companion/test/prim-traffic-empty-periods.test.js, README.md, and CHANGELOG.md. Host verification does not certify a newly packaged application on a native watch.