public-transport / hafas-client

JavaScript client for HAFAS public transport APIs.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

HAFAS answers often with "ECONNRESET"

VanDerLars opened this issue · comments

Since some days we see the following behavior:

We make a call over Hafas Client and we get the following error message instead of the result:
{"error":{"message":"request to https://reiseauskunft.bahn.de/bin/mgate.exe?checksum=660a896737929f3e112c5e5679151ba7 failed, reason: read ECONNRESET","type":"system","errno":"ECONNRESET","code":"ECONNRESET"}}

When we retry the exact same call one or two times, then the result comes often.

Also we monitor the Hafas Endpoint of Deutsche Bahn (reiseauskunft.bahn.de) with updown.io. The availability constantly got worse over the last weeks.
CleanShot 2023-06-23 at 09 12 31@2x

What could be the reason?

Do you know a way how to avoid the ECONNRESET error?

ECONNRESET is the error code that Node.js returns if the TCP has been closed unexpectedly, usually either due to a lossy connection or due to a firewall closing it or dropping packets.

It might be that they're rate-limiting requests from your servers' IP addresses. I've observed similar behaviour with my servers.

I would suggest

  • checking how many requests you're actually sending to them.
  • investigating if this error appears with specific requests (e.g. specific HAFAS methods or specific stop IDs) only, in oder to rule out other possible causes.
  • implementing a caching mechanism. – You could use cached-hafas-client, but it has rather conservative default TTLs, so consider tweaking them.
  • possibly requesting from more IP addresses.

Also we monitor the Hafas Endpoint of Deutsche Bahn (reiseauskunft.bahn.de) with updown.io. The availability constantly got worse over the last weeks.

Do you monitor their endpoint directly, or do you monitor your API which pings their endpoint?

Do you monitor their endpoint directly, or do you monitor your API which pings their endpoint?

We monitor their endpoint directly.

Actually, we were able to reproduce the issue locally. So, it seems that even if they have rate-limiting, it is not IP-based.

Actually, we were able to reproduce the issue locally. So, it seems that even if they have rate-limiting, it is not IP-based.

I'm not entirely sure about this. I've definitely run into IP-based rate limits even while developing locally, albeit with many requests. There might also be multiple limits in place, based on multiple factors.

I'll close this Issue, given that I don't have control over how HaCon and/or DB run the HAFAS endpoint.

You're very welcome to post more findings about the ECONNRESET errors though!

what we see:

  • ECONRESET seemingly happens randomly
  • exact same request sometimes work, sometimes not
  • no matter if we run it locally or in production, so there's no IP blocking
  • there might be an algorithm when ECONRESET happens, but we see no pattern
  • we "solved" by just retrying the same calls. the second, least the third attempt mostly work

we "solved" by just retrying the same calls. the second, least the third attempt mostly work

Note that hafts-client provides retry.js for this. Its current logic merely aborts on ENOTFOUND errors and retries otherwise:

hafas-client/retry.js

Lines 15 to 31 in 4cb7062

const retryingRequest = (...args) => {
const attempt = () => {
return request(...args)
.catch((err) => {
if (err.isHafasError) throw err // continue
if (err.code === 'ENOTFOUND') { // abort
const abortErr = new retry.AbortError(err)
Object.assign(abortErr, err)
throw abortErr
}
throw err // continue
})
}
return retry(attempt, retryOpts)
}
return {

@derhuerst thanks for the tipp.

@Issam-Jendoubi could ne a better approach, let's discuss that.