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" and "Take it to the engineering bridge" are real answers.
1
In plain terms. The overnight job that refreshes work-order details (vendor on file, activity) can only get through about 200 of Situs's ~450 open work orders a night, so some go more than two days without a refresh and it pages every morning. Which fix should we build?
The full question, as raised
wo_enrichment sweep: queue ~448/day (all situsgroup, 52 properties) vs ~200 drained per 640s serial drain at ~3.2s/WO; 4 properties breach the 48h budget-staleness bar daily (Sentry JAVASCRIPT-NEXTJS-1HW, 18 events since 10-15). #23147 cut unreached 7758->248 by skipping Work Done rows but the remaining open queue is ~2.2x capacity. Budget is already the full Lambda; weekly cadence for Situs still breaches the 14d bar; widening 48h is a bandage (and high-risk under the 14-day rule). Sampled on one Situs property (property-41): 42/105 queued open rows created >90d ago, 74/105 >30d, mostly AppFolio status New. Which throughput lever?
Why, and what was tried
The session raising this recommends: Refresh work orders opened over 30 days ago weekly, new ones daily Cuts the nightly load by roughly two-thirds on the sampled building with no new AppFolio pressure or schedule change; long-open jobs rarely change. Tried first, unsuccessfully: Measured the run (448 queued, 200 done in 642s, all Situs), ruled out a bigger time budget (already the Lambda max), Situs-weekly (still breaches), and widening the bar (bandage). fable-decide on the three levers returned no output within 5 minutes.