No connections found: Handle changes of location IDs

[airon90]

An error is shown when looking for some stations, e.g. Dateo, Milano and Garibaldi Fs, Milano. I don't know if it is a Navitia problem or Transport problem, so I start reporting the bug here ;)

[grote]

Do you still have the same problem?

[airon90]

Yes, I'm on holiday and I come back home the day after tomorrow. I'll explain the problem better then

[airon90]

Could you confirm that the latest version of the beta app is still 1.1.3?
This bug seems related to a problem of Navitia APIs as when one searches for "Dateo", the app shows two entries named both "Dateo, Milano", as you can see from the screenshot.

If I choose the first one, this error is shown:

If I choose the second one, all goes well.

Could you check if it is a problem of Navitia APIs, so that I close this bug and open another one in Navitia's forum? Thank you very much!

[grote]

My theory is that the Italy provider changed its location IDs, so when you search it finds the old one Transportr saved as a favorite and the new one. If you use the old one with the wrong ID, you get the error.

I would need to investigate more to confirm this theory. You could help by checking logcat when you search for both locations and compare the IDs.

[airon90]

I'd like to help you. Would you be so kind to tell me what to do? I don't know what logcat is 😕

[grote]

Some quick pointers:

• If you use Linux, you can install android-tools-adb
• logcat just shows all log messages from your phone and your apps. Type adb logcat when your phone is connection in debug mode to your computer
• If you are root on your phone, there's logcat apps you can use: https://f-droid.org/repository/browse/?fdfilter=logcat&fdpage=1&page_id=0
• Then pay attention what Transportr logs after you pressed the search button

[airon90]

I finally succeeded in using logcat. Here is the output. I hope this helps!
I don't know why I activated the option "No metro lines" but don't care about it.

[grote]

Thanks! That's a good start. I only found this once here:

D/AsyncQueryTripsTask(14289): From: Location{STATION, stop_area:OMI:SA:CTP17390, 45468438/9217189, place=Milano, name=Dateo}
D/AsyncQueryTripsTask(14289): To: Location{STATION, stop_area:OMI:SA:CTPGARIBALDIFS, 45483640/9186742, place=Milano, name=Garibaldi Fs}

It would be interesting to know how this changes with the second Dateo that works.

If you could just post these two lines here, that would help.

[airon90]

D/AsyncQueryTripsTask(  337): From: Location{STATION, stop_area:OMI:SA:CTP12166, 45468119/9217718, place=Milano, name=Dateo}
D/AsyncQueryTripsTask(  337): To: Location{STATION, stop_area:OMI:SA:CTPGARIBALDIFS, 45483640/9186742, place=Milano, name=Garibaldi Fs}

[grote]

Thanks, so Dateo was stop_area:OMI:SA:CTP17390 before and now is stop_area:OMI:SA:CTP12166. Apparently, the old ID doesn't work anymore :(
Would be interesting to know why this ID changed and how app developers are supposed to handle those changes.

[airon90]

If you want to know why they changed IDs to stops and how handle future changes, you can send an email to info@amat-mi.it (I can help you in translating it into Italian).
Now that you know that Dateo changed its ID, how can I delete the old Dateo?

[grote]

Deleting old favorites is not possible at the moment, because normally(!!!) they don't change. Before talking to amat, I think we should talk to Navitia, because it might have been their fault the IDs changed.

[airon90]

Are you going to ask Navitia about ID changing or should I do that?

[grote]

Meanwhile, I talked with Navitia two times in IRC. There's no real solution so far and probably none coming soon.

We should at least try to show a meaningful error message and a way to recover from that error.

In the API response, there should be a 404 error with an ID unknown_object.
Maybe there is also a response.error.id with one or more of these values: [no_origin, no_destination, no_origin_nor_destination]. But more likely, the unknown stop ID can be found in response.error.message.

Someone would need to investigate the exact API response behavior and then return a proper error code from the AbstractNavitiaProvider (in PTE). Not all that difficult, but needs to be done.

[grote]

According to PTE upstream, the issue is generally an unsolved problem:

https://groups.google.com/d/msg/public-transport-enabler-discuss/eZK5MdDEDBE/d6rFSe6_AAAJ

[grote]

@dennisguse the code has now somewhat settled, so that you could think about implementing this. I suggest to discuss the general approach here though before starting to write actual code.

[dennisguse]

@grote Sounds good! I will try to take a look after Xmas!

[ialokim]

@dennisguse the code has now somewhat settled, so that you could think about implementing this. I suggest to discuss the general approach here though before starting to write actual code.

@grote Do you remember what was the idea to implement at this point? As this is a general problem and happens in various providers it would be nice to at least be able to somehow cope with this without clearing the entire app data.

[grote]

I think the rough idea was to see if we get reliable info to determine that an ID is no longer valid, then either delete everything saved with that ID, so that people can re-add things with the proper ID or try to find the new Id and replace the old one.