Trip queries currently fail for most requests in /hsl endpoint

[hsldevcom]

Trip queries currently fail for most requests in /hsl endpoint

[PasiSalenius]

Okay the fuzzyTrip query seems to work reliably if given a later date

{
  fuzzyTrip(route: "HSL:1001", direction: 1, date: "20170214", time: 36600) {
    gtfsId
  }
}

Couldn't the issue be solved by updating the GTFS data at the same time for all API endpoints?

[hannesj]

Couldn't the issue be solved by updating the GTFS data at the same time for all API endpoints?

We're trying to keep the data stable, the issue is that if one instance restarts, it might receive newer data depending in which order some of our containers have been updated after publishing new data to the production environment. This issue is something we try to solve, but hasn't been tackled yet.

[siren]

Hi and thanks for the report. We had different versions of the dataset running on the beta environment during Friday to Sunday morning and that might have caused problems similar to what you described.

We have corrected the problem and the api should now operate as expected.

[PasiSalenius]

Seems to be back to normal, thanks!

[PasiSalenius]

This issue seems to have crept back.

Here's an example graphQL query that fails with "trip": null most of the time.

{
  trip(id: "HSL:1001 3_20170130_Ti_2_1010") {
    gtfsId
  }
}

I hope this would get more reliable, as it's core functionality of the API, at least for my app.

[tuukka]

Thanks for the report, but please use fuzzyTrip instead of trip.

[PasiSalenius]

Why? fuzzyTrip query is not for the same purpose as basic trip(id:) query. One finds the correct Trip object based on it's data, the other queries the Trip directly.

This issue also breaks beta.reittiopas.fi for example here
https://beta.reittiopas.fi/linjat/HSL:1054/pysakit/HSL:1054:1:01/HSL:1054_20170130_Ti_2_1012

[PasiSalenius]

Also, here's the corresponding fuzzyTrip query that fails with the exact same pattern:

{
  fuzzyTrip(route: "HSL:1001", direction: 1, date: "20170130", time: 36600) {
    gtfsId
  }
}

[tuukka]

@PasiSalenius Because HSL trip id's are not stable. The fuzzyTrip query works if you don't try to query too much in the past (HSL's GTFS data does not cover dates in the past.)

[PasiSalenius]

@tuukka I think you're not understanding the issue. I am simply repeating the same query here. It doesn't make any difference whether I use trip() or fuzzyTrip(), they both fail randomly with null result, for the same exact query with the same parameters.

To test, copy either the trip() or fuzzyTrip() query to a graphQL console and repeat the request at short intervals. You'll see null responses.

[PasiSalenius]

I know Trip ids are not stable, but this is a Trip id I have received from the same graphQL API under a second earlier. They should be more stable than that, right?

[tuukka]

@PasiSalenius The reason your fuzzyTrip example was failing was that you had the date too much in the past. Or can you make it fail if the date is today?

Right, we'll try to have the id's more stable than one second, but it can happen that we have two versions of the data running in parallel API instances like right now.

We'll try to improve but if this is important to you, you can improve the situation as well.

[PasiSalenius]

@tuukka The way I found the beta.reittiopas.fi page that fails to load is that I planned a trip, for today, departing now, within HSL area. I did that 21 minutes ago.

Loading the page that should display the Trip pattern and timetable fails to load. How is this querying data too much in the past?

[tuukka]

Yes, we'll try to improve the updating. But I don't think it will ever happen on the same second between all the servers. And even if it did, some users might still get caught by the change if they tried to perform your operation right at that time.

[PasiSalenius]

That's of course acceptable, what I'm getting at is that I wish it didn't stay like this for days.

[siren]

I am closing this because I think that the related data updates are now happening synchronously enough