ICPI Parity Verification

Scope

This sprint verified parity between:

• old colocated ICPI hosting in services/svc-tenders
• new extracted ICPI runtime in services/svc-icpi
• gateway fallback mode using TENDERS_SERVICE_URL
• gateway cutover mode using ICPI_SERVICE_URL=http://localhost:4021

The goal was to verify behavior, not to remove the old host.

Runtime Context Used

• svc-auth on http://localhost:4100
• old ICPI host via svc-tenders on http://localhost:4020
• new ICPI host via svc-icpi on http://localhost:4021
• gateway via services/api on http://localhost:4001

Verification was executed against live local processes. Read and write checks were performed from the same Node runtime family that hosted the services so localhost behavior stayed faithful to the actual process boundary.

Routes Checked

Direct old-host vs new-host parity

• GET /icpi/prices?page=1&pageSize=1
• GET /icpi/suggest?query=cement&region=GE&limit=5
• GET /icpi/latest/ICPI_PARITY_MISSING?region=GE
• GET /icpi/estimate?itemCode=&quantity=abc
• GET /icpi/estimate?itemCode=ICPI_PARITY_MISSING&quantity=2&region=GE
• POST /icpi/upsert with no bearer token
• POST /icpi/upsert with valid-signature access token whose principal could not be resolved

Gateway fallback parity

Compared gateway GET/POST /api/v1/icpi/* responses against direct old-host responses while ICPI_SERVICE_URL was unset and TENDERS_SERVICE_URL=http://127.0.0.1:4020.

Routes checked:

• GET /api/v1/icpi/prices?page=1&pageSize=1
• GET /api/v1/icpi/suggest?query=cement&region=GE&limit=5
• GET /api/v1/icpi/latest/ICPI_PARITY_MISSING?region=GE
• GET /api/v1/icpi/estimate?itemCode=&quantity=abc
• POST /api/v1/icpi/upsert with no bearer token
• POST /api/v1/icpi/upsert with valid-signature but unresolved principal token

Gateway cutover parity

Compared gateway GET/POST /api/v1/icpi/* responses against direct new-host responses while ICPI_SERVICE_URL=http://127.0.0.1:4021.

Routes checked:

• GET /api/v1/icpi/prices?page=1&pageSize=1
• GET /api/v1/icpi/suggest?query=cement&region=GE&limit=5
• GET /api/v1/icpi/latest/ICPI_PARITY_MISSING?region=GE
• GET /api/v1/icpi/estimate?itemCode=&quantity=abc
• POST /api/v1/icpi/upsert with no bearer token
• POST /api/v1/icpi/upsert with valid-signature but unresolved principal token

Parity Status

Confirmed parity

• GET /icpi/prices: 200 and identical JSON shape
• GET /icpi/suggest: 200 and identical JSON shape
• GET /icpi/latest/:itemCode not-found path: 404 with reasonCode=icpi_not_found
• GET /icpi/estimate invalid-input path: 400 with reasonCode=invalid_estimate_query
• GET /icpi/estimate not-found path: 404 with reasonCode=icpi_not_found
• POST /icpi/upsert missing bearer token: 401 with reasonCode=missing_bearer_token
• POST /icpi/upsert unresolved principal: 401 with reasonCode=principal_resolution_failed
• gateway fallback mode matched old colocated host on all checked routes
• gateway cutover mode matched new svc-icpi runtime on all checked routes
• rollback mode matched old colocated host again after removing the ICPI_SERVICE_URL override

Mismatches Found

No ICPI route mismatches were found in the checked parity set.

Additional Findings

Non-ICPI auth-service fragility exposed during rehearsal

Severity: MEDIUM

While probing /auth/me, svc-auth crashed when given a syntactically valid JWT whose sub was not UUID-shaped. That is not an ICPI runtime mismatch, but it is a real behavior exposed by the rehearsal.

Observed shape:

• request target: GET /auth/me
• token: valid signature, non-UUID sub
• result: svc-auth process crash caused by database UUID parsing, instead of a clean non-OK auth response

This did not block ICPI parity verification because:

• ICPI parity was rechecked using a valid-signature token with UUID-shaped sub
• both old and new ICPI runtimes then matched on principal_resolution_failed
• gateway behavior also matched in fallback, cutover, and rollback modes

Severity Summary

• ICPI route parity drift: NONE OBSERVED
• gateway cutover drift: NONE OBSERVED
• rollback drift: NONE OBSERVED
• unrelated auth-service robustness issue: MEDIUM, outside ICPI route parity itself

Notes

• Current checked parity is strongest on read routes plus protected-write denial paths.
• A future sprint can add fully authenticated happy-path upsert parity if a stable seeded principal/session fixture is available.