laterRef is null in v6 API Response

ahmadhash commented 3 months ago

Description:

When I hit the following API endpoint:

Request:

https://v6.db.transport.rest/journeys?from=8400058&scheduledDays=true&transferTime=7&firstClass=false&bike=false&tickets=false&nationalExpress=true&national=true&regionalExp=true&regional=true&suburban=true&bus=false&ferry=false&subway=false&tram=false&taxi=false&transfers=2&stopovers=false&departure=2024-12-13T12:00:00.000Z&to=8011160&results=20

Response:

{
    "earlierRef": null,
    "laterRef": null,
    "journeys": [
        // some journeys
    ],
    "realtimeDataUpdatedAt": 1721660783
}

I notice that the laterRef field is null.

However, when I use the previous version (v5), the response is different: Request:

https://v5.db.transport.rest/journeys?from=8400058&scheduledDays=true&transferTime=7&firstClass=false&bike=false&tickets=false&nationalExpress=true&national=true&regionalExp=true&regional=true&suburban=true&bus=false&ferry=false&subway=false&tram=false&taxi=false&transfers=2&stopovers=false&departure=2024-12-13T12:00:00.000Z&to=8011160&results=20

Response:

{
    "earlierRef": "3|OB|MT#14#535079#535079#535431#535431#0#0#565#535016#1#0#1050#0#0#-2147483648#1#2|PDH#0d35376a84fe1e546b4fa0ee3930eb27|RD#13122024|RT#125600|US#0|RS#INIT",
    "laterRef": "3|OF|MT#14#535118#535118#535502#535516#0#0#565#535080#3#0#2#0#0#-2147483648#1#2|PDH#0d35376a84fe1e546b4fa0ee3930eb27|RD#13122024|RT#125600|US#0|RS#INIT",
    "journeys": [
        // some journeys
    ],
    "realtimeDataFrom": 1721660963
}

As shown, both earlierRef and laterRef are present in the response.

Issue Summary:

In version 6, after July 24, 2024, the laterRef field is consistently null in the API response. This behavior is not observed in version 5, where laterRef is correctly populated.

Why laterRef is Needed:

I need the laterRef field because my project involves creating itineraries that include rail components. Users may plan trips for the future, and it is essential to store journey references for accurate itinerary management.

derhuerst commented 2 months ago

This has been the case for quite a while: https://github.com/public-transport/hafas-client/blob/6.3.1/test/e2e/db.js#L253

Not sure if we can do something about it though, I haven't investigated. Upgrading to a new ver might work?

derhuerst commented 2 months ago

https://github.com/public-transport/hafas-client/issues/287#issuecomment-1609121167 sounds related. cc @lamBOOO

derhuerst commented 2 months ago

Although it doesn't solve the problem, https://github.com/derhuerst/db-rest/pull/46 will let you specify the routing mode in db-rest#6 a.k.a. https://v6.db.transport.rest, once merged & deployed.

lamBOOO commented 1 month ago

Sorry for the delay.

Although it doesn't solve the problem, https://github.com/derhuerst/db-rest/pull/46 will let you specify the routing mode in db-rest#6 a.k.a. https://v6.db.transport.rest/, once merged & deployed.

Why doesn't it solve the problem? I would expect that different routing modes for the v6 call would yield earlierRef and earlierRef or am I missing something? Isn't this issue here exactly about https://github.com/derhuerst/db-rest/issues/31#issuecomment-1609128384? 🤔

derhuerst commented 1 month ago

It is a workaround. Last time I checked, you could choose a non-REALTIME routing mode and get earlierRef and laterRef. But the endpoint didn't seem to allow pagination on realtime-routed results/journeys.

lamBOOO commented 1 month ago

Ahh okay, now I understand. So it's simply not possible anymore with REALTIME to have pagination?

Can we do something about it? Reverse engineering another "endpoint" (e.g., the desktop website still has pagination for realtime data).

derhuerst commented 1 month ago

So it's simply not possible anymore with REALTIME to have pagination?

I assume HAFAS doesn't support this.

Can we do something about it? Reverse engineering another "endpoint" (e.g., the desktop website still has pagination for realtime data).

I'm not sure if the DB website actually does routing like the HAFAS mgate.exe REALTIME mode (routing on the realtime-updated graph), or if it just does it like the HYBRID mode (routing on the schedule data graph, then update results with realtime data, then filter results). I'd say that you'll be able to find some specific cases to tell if you dig long enough.
Even if the website supports it, that doesn't help hafas-client much because it's a completely different system, AFAIK with a non-stable public API (if any).

lamBOOO commented 1 month ago

I assume HAFAS doesn't support this.

Hmm okay, I don't know the system at all tbh.

I checked with my iOS Navigator app and they seem to still use the mgate.exe with REALTIME there.

In general, what is the advantage of REALTIME to HYBRID? I mean, using the mobile apps (although they use HYBRID) feels like "real-time" 🤔

public-transport / hafas-client