Fix index out of range for stop_times last arrival of multi-section run

[traines-source]

I stumbled upon a motis crash libc++abi: terminating due to uncaught exception of type cista::cista_exception: bucket::at: index out of range with the 06.01.2025 DELFI GTFS and this query (didn't dare to try it out on one of the public instances...):
/api/v1/stoptimes?stopId=gtfs_de%3A03159%3A33817%3A%3A8&time=2025-01-18T13%3A08%3A00.000Z&arriveBy=true&n=10

Occurs in nigiri/src/rt/frun.cc#L105 for the last stop of multi-section trips, because it would always look for a event_type::kDep.
I.e. an alternative fix with less (interface) changes would be to make get_trip_index(ev_type) in nigiri more robust, but would then still lead to wrong results for the trip_id at stops where the trip_id switches (if I understand correctly).

[felixguendling]

Thank you! 🌠

Do you think it makes sense to add a utl::verify somewhere to prevent this from happening in case the wrong event type would be supplied in the future?

[felixguendling]

Hmm.. it already fired an exception. I would've hoped that this gets caught somewhere in the HTTP handler.

[traines-source]

Yes rather than utl::verify (which would basically have the same result, just with a nicer error message, right?) I would maybe make get_trip_index more robust (but now that the event_type param is everywhere it forces you to think about it, so it should be ok like that as well). And yes I was surprised that this took down motis entirely, not only the thread or sth.

[felixguendling]

My hope was that at least the "catch all" here would've caught it:
https://github.com/motis-project/net/blob/30f8b05a435af6f8327376d6e95089b4341ac4f7/src/web_server/query_router.cc#L98-L112

And in case this doesn't catch it, there's this:
https://github.com/motis-project/net/blob/30f8b05a435af6f8327376d6e95089b4341ac4f7/include/net/web_server/query_router.h#L70-L80

Not sure what went wrong here.

[felixguendling]

Ah. I guess it's because those methods in frun are marked noexcept. Maybe it would be better to just get writ of noexcept in MOTIS code completely except if it's proven to improve performance (which is rarely the case - and if it improves performance it's usually not really a big difference).

[traines-source]

Ah yes. And maybe we should, because a dying motis is a bad thing :)