Pick an option on each card and press Done; your answer goes straight
back to the session. The raiser's pick is marked. "I'm not sure" is a real answer.
12 questions on this
In plain terms. What should we do about the kind of gap that let tonight's text message fail silently? Two decisions below — closing it everywhere, and proving it stays closed.
0 of 2 answered
1Tonight's after-tour staff check-in (sendTourStaffCheckin / tour-checkin-ask.ts) silently no-op'd at a Western Slope property because it resolved the outbound Twilio number via resolvePropertyFromNumber (property code-map + Property.twilioNumbers only, no org-level fallback), while every other send type to the same recipient (tour alerts, staff thread, reminders, TechSmsDispatch) uses resolveOutboundAddress (which does fall back to an org-level line). Western Slope has only an org-level Clara line, so this check-in has never fired there. Tactical fix in flight and open (PR #14496, [urgent], MERGEABLE) switches the check-in to the shared resolver and logs a true no-line case loudly instead of swallowing it. Question: commit to (a) one outbound-number resolver for every send type, deleting the older one, and (b) treating any infra-reason skip as a paged/alerted event rather than a silent no-op? Touches the portfolio-architecture lines/attachments model (lines attached to org vs property) so the resolver's shape should come from that design.
In plain terms. Should every outgoing text use one shared way of finding its sending number, with an alert on any send that gets skipped? Tonight one message vanished silently because a second, older lookup couldn't handle that building's setup. Tonight's case already has a fix underway.
Why the raiser recommends it
The session raising this recommends: Yes — one lookup everywhere, alert on every skip A silent skip looks identical to success today; one resolver kills the bug class and an alert catches the next gap before a customer does.
2Add a nightly per-company dry run that proves every staff-facing outbound message type can resolve both a from-number and a recipient, for every customer. Pair it with test properties deliberately shaped to mirror each real customer's line layout (e.g. a Fairhaven-shaped test property with an org-level line only, no per-property lines) so a Western-Slope-shaped gap is caught in a nightly run instead of in production. Follow-on to the send-path question — same portfolio-architecture lines/attachments design should drive both.
In plain terms. Should we add a nightly check proving every customer can receive each staff text type, using test setups shaped like each real customer's phone-line setup? Tonight's customer has one shared company-wide line, which nothing today would have caught in advance.
Why the raiser recommends it
The session raising this recommends: Yes — nightly check plus matching test setups Without a check and realistic test shapes, the only way we find the next customer-specific gap is a customer finding it first.
Why, and what was tried
Tried first, unsuccessfully: 001-f3 diagnosed the exact cause and already has a tactical fix in flight and open (PR #14496, MERGEABLE) for tonight's case. The broader architecture call touches the portfolio-architecture lines/attachments model, so it's routed to Gera rather than decided inside the tactical fix.
37f41ddb is parked on this.
Answered and withdrawn (1)
b90813823 Tonight a staff text message silently failed to send at one customer because of a gap in how we find the right phone number to send from. Two related calls below — how to close that gap everywhere, and how to prove it stays closed. What do you want to do? — withdrawn