Lamassu: GBFS feed stadtwerk_tauberfranken is not available

[hbruch]

@ThorstenFroehlinghaus reported that the stadtwerk_tauberfranken feed is currently not accessible:

A feed is generated and also x2gbfs logs report no suspicious warning:

INFO:x2gbfs.moqo:Vehicle 1009532230 has no station (is in use), will be removed from feed
INFO:x2gbfs.moqo:Vehicle 2145593292 has no station (is in use), will be removed from feed
INFO:x2gbfs.moqo:Vehicle 1330444111 has no station (is in use), will be removed from feed
INFO:x2gbfs.moqo:Vehicle 1819803692 has no station (is in use), will be removed from feed
INFO:x2gbfs:Updated feeds for stadtwerk_tauberfranken

[hbruch]

Lamassu validation reports don't show any issue:

However, Lamassu logs report:

{"serviceContext":{"service":"lamassu"},"message":"Caught exception in ForkJoinPool\njava.lang.IllegalStateException: java.lang.IllegalStateException: Expected value (nonempty with characters A-Z, a-z, ø, Ø, æ, Æ, å, Å, underscore, \\ and -), found vw_id.3\n\tat java.base/
...

The vw_id.3 vehicle type is declared in stadtwerk_tauberfranken/vehicle_types.json and IMHO should be accepted by Lamassu (see e.g. https://github.com/MobilityData/gbfs/pull/545 for a recent clarification regarding supported ID types). I'll raise an issue thereThis issue is already tracked in Lamassu but in the meantime, will map dots to underscore in X2GBFS.

[ThorstenFroehlinghaus]

Is there a way to systematically detect such kind of problems, where the data source is ok, but the lPL processing is not. In grafana, stadtwerk_tauberfranken has the status 'OK'.

[derhuerst]

@hbruch If the validation logs an issue, it should also be reflected in the app_lamassu_gbfs_validation_feederrors{system="stadtwerk_tauberfranken"} metric, right?

@ThorstenFroehlinghaus We could then build a dashboard entry and/or set up alerting based on that metric. Also, we could use the recently added Blackbox Exporter to monitor the GBFS feed URL for its HTTP status code & Last-Modified header.