search

public-transport / hafas-client

JavaScript client for HAFAS public transport APIs.
ISC License
278 stars 54 forks source link

Questions about HAFAS errors #232

Closed gaudes closed 3 years ago

gaudes commented 3 years ago

Hi Janis,

I've integrated more reporting for HAFAS errors in my ioBroker Adapter as discussed here:

https://github.com/public-transport/hafas-client/issues/231

We are using Sentry for error reporting.

Before I've filtered HAFAS errors out. So now I get a few HAFAS specific errors as issues in Sentry reported and I need help if these errors are relevant:

Field Message
Error.code CGI_NO_SERVER
Error.isHafasError True
Error.message CGI: server could not be reached
Field Message
Error.code CGI_READ_FAILED
Error.isHafasError True
Error.message CGI: Server died during request execution
Field Message
Error.isHafasError True
Error.message Gateway Timeout

IMHO, these are temporary errors in HAFAS. So you and me can't do anything to fix, so I will filter these errors out.

What's your opinion ? Is there a list of "ignorable errors" ? Or can you extend the error object with something like "isHafasIgnorableError" ?

Thanks and regards,

Ralf

derhuerst commented 3 years ago

In most of the cases, you can ignore these errors, as they "just" describe the fact that some important component in the backend is not available.

But: From my experience, there are some queries that consistently cause such "backend is down" errors because they crash the backend. So the tricky part is finding requests that often cause these errors, and igoring cases when it just happens to be down. I don't have a specific example right now, but #228 & #230 are similar cases where this distinction is not clear.

Maybe you can find a pattern among the reported errors, e.g. a specific call or stop ID?

gaudes commented 3 years ago

Ji Janis,

I've not published this version to npm, so all errors come from my own installation :)

In my installation I use a common start and stop. The program requests every 5 minutes the journeys. It runs since 10.06.

So there must have been more than 3700 requests since 10.06.

11 errors occured during these requests, the others were successfull.

So I would ignore these errors in reporting to Sentry by exclude them by Error.code or Error.message.

If a query consistently causes errors, the user can report it.

I'll watch out for other errors.

Thanks and regards,

Ralf

derhuerst commented 3 years ago

👍 – you could also mute it in Sentry by a combination of origin, destination and options (except time) in order not to mute too much