|
Some checks are pending
CI / verify (push) Waiting to run
A finalize run against a store whose phone number still had a pending
carrier order surfaced three unrelated-looking 400s (add-number,
caller ID = LOCATION_NUMBER, auto attendant "number already used")
that all traced back to the number not being attached, plus a
spurious "DECT network pre-check failed" warn when the location had
never had a DECT network before.
Fixes:
- addPhoneNumbersToLocation now translates the raw
NUMBER_HAS_PENDING_ORDERS payload into an actionable operator
message ("wait for the carrier order, then re-run /finalizeStore").
Original error preserved as .cause. Extracted as pure
translateAddNumberError so it can be unit-tested.
- finalizeStore marks the phone-number-add step { critical: true } so
finalize aborts immediately on that failure instead of cascading
three downstream errors that bury the root cause.
- findDectNetworkInLocation treats HTTP 404 as "no networks yet"
(Webex returns 404 for that state, not an empty list), so the
finalize pre-check stops warning on the normal first-time path.
The remaining warn now includes status code for anything that does
reach it.
Tests: 4 new cases in test/locations.test.js locking down the
translator behavior against the exact Webex payload shape.
Co-authored-by: Cursor <cursoragent@cursor.com>
|
||
|---|---|---|
| .. | ||
| dect.test.js | ||
| google.test.js | ||
| greetingSelector.test.js | ||
| helpers.test.js | ||
| http.test.js | ||
| locations.test.js | ||
| mac.test.js | ||
| phones.test.js | ||
| setup.js | ||
| stepRunner.test.js | ||
| webexClient.test.js | ||