Open e-lo opened 2 years ago
This one is interesting. With the current design of the validator, we could only generate this for the webapp but not the batch validator, because the batch validator doesn't know what the source of the binary protobuf file is (it just reads the binary file off disk, where it was placed by the user).
Thinking more, we could add another optional parameter to the batch validator that's the source URL of the feed that would allow us to generate this error in batch validation too. The feed URL could also be used in batch validation for other rules that would need to query the endpoint, like https://github.com/MobilityData/gtfs-realtime-validator/issues/118 (endpoint returns protobuf format). If we do this we should be clear which rules trigger network communication to the feed URL and clear what the behavior is if that network call fails.
I'd be curious to hear from others what they think of embedding rules in the batch validator that require network communication to fetch a feed.
See also the discussion in https://github.com/MobilityData/gtfs-realtime-validator/issues/29#issuecomment-1071757182 for a command-line monitoring service that might fetch multiple times over a longer period of time.
Relevant Best Practice text: