I'm parked on you

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. When a staff member answers Clara by email, the mail checker writes Clara's follow-up right there, and that can take longer than the checker's one-minute limit (it cut off twice this week). Should we hand that follow-up to the slower background worker that already handles long email work, or give the mail checkers more memory and time?

The full question, as raised

Both mail pollers (propflow-gmail-company-inbox-poller-prod and its Outlook twin propflow-company-mailbox-poller-prod; 256MB/60s) run a full Clara turn INLINE: deliverInboundEmail -> process-inbound-email -> releaseMatterOnStaffReply. TICK_SOFT_BUDGET_MS (45s) gates BETWEEN messages only; nothing bounds one message's delivery. Timeouts: 2026-10-29 and 2026-10-31T14:54Z (request 791dfc22: staff team-note answer -> prospect SMS turn, FairHousing ~19s, held draft at 14:55:07, killed 14:55:31). Both pollers sit at Max Memory Used 254-256MB p50 every day for 10+ days (clipped, cf. appfolio-sync-memory-config drift test). inbound-processor runs the same kind of work at 512MB/600s ('LLM calls can take 60-180s'). Option A: poller hands the staff-reply release to an async lane and returns. Option B: raise poller memory to 1024 + timeout, rely on the poll lease for overlapping ticks. Side gap: poller env lacks CONVERSATION_EVENTS_QUEUE_URL (turn_settled not published from poller-ingested mail).

Hand follow-ups to the background workerthe raiser's pick Give the mail checkers more memory and time I'm not sure — go find out Take it to the engineering bridge

Why, and what was tried

The session raising this recommends: Hand follow-ups to the background worker
The cut-off turn spent most of its time waiting on AI calls, so more memory only partly helps; the background worker already has a 10-minute limit for exactly this work.
Tried first, unsuccessfully: Read CloudWatch Duration/REPORT stats for both pollers over 10 days, the timed-out invocation's full log, the poller's time-budget code, and both deploy configs; confirmed no open decision or prior fix PR for this cause. Did not ship a memory-only PR because it would not fix an AI-latency-bound turn and touches Clara's reply path, which is under review hold.

f7f25f1e is parked on this.

Pick an option above, then press Done.