A time reserve for Alice's answer

1.8 seconds for the source, 2.8 for the dialogue. The cache helps survive a failure.

guap-alice cover

In Guapik I gave the external request 1.8 seconds and the main dialogue handling 2.8. After a loading error there still has to be time to pick a fallback answer and assemble the reply.

The dialogue is wrapped in asyncio.timeout(settings.handler_timeout). A FALLBACK is set up outside it in advance: on timeout the webhook returns it in the normal response structure. Reading the request body gets its own second, and that stage also counts toward the total handling time.

The timetable cache follows two rules. For the first hour an entry is fresh and can be served without asking SUAI. After an hour I try to refresh it. If the source is down, I allow the old entry for another 24 hours beyond the fresh interval.

In the code the age is compared with cache_ttl + stale_ttl, which with these settings means under 25 hours. After that the old timetable is no longer served.

Waiting on a rate limit also eats into the dialogue budget. So one HTTP client timeout is not enough: there can be a queue before the network and page parsing after it. A limited cache reserve is useful for a timetable. Money or room availability need a different refresh policy.

← All projects

Contacts