Navitia: BlockedException when searching directions

[bre75]

[

[grote]

can't reproduce this here with the paris provider

[bre75]

It was working as a charm until the upgrade. On February 7, 2019 6:02:49 PM GMT+01:00, Torsten Grote <notifications@github.com> wrote: can't reproduce this here with the paris provider — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#583 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ATuvAP11HIrKVfTvVzyyLcGzlryTbwdrks5vLFw5gaJpZM4ansZJ>.

[bre75]

This is strange... I tried this morning for a trip in Paris and it's working. Then i tried again for the same trip than yesterday that was in Paris suburb and then i got again the error. On February 7, 2019 6:02:49 PM GMT+01:00, Torsten Grote <notifications@github.com> wrote: can't reproduce this here with the paris provider — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#583 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ATuvAP11HIrKVfTvVzyyLcGzlryTbwdrks5vLFw5gaJpZM4ansZJ>.

[jeanrjc]

Same issue for me since the update.

de.schildbach.pte.exception.BlockedException: https://api.navitia.io/v1/journeys?from=stop_area%3AOIF%3ASA%3A8775863&to=stop_area%3AOIF%3ASA%3A8739100&datetime=20190219T090456&datetime_represents=departure&min_nb_journeys=6&depth=0&walking_speed=1.12
de.schildbach.pte.util.HttpClient.getInputStream(HttpClient.java:292)
de.schildbach.pte.util.HttpClient.get(HttpClient.java:209)
de.schildbach.pte.util.HttpClient.get(HttpClient.java:197)

[grote]

Does it happen on all searches? Also departures and nearby stations? Also non-saved direction searches?

[jeanrjc]

It seems to bug when it involves saved (starred) directions. Using history is ok for the few tries I've made.
I can't really try all combinations, so I can't say which one works for sure. But directions I saved are not working, but if I set the same locations by hand and if don't chose the saved locations that are proposed, it works.

[grote]

Strange. Might be similar to #207. I have no time to investigate this. Maybe somebody with a bit of technical knowledge can do this.

[bre75]

In my case history is only working for Paris but not the suburb or if suburb involved. On February 19, 2019 4:44:48 PM GMT+01:00, jeanrjc <notifications@github.com> wrote: It seems to bug when it involves saved (starred) directions. Using history is ok for the few tries I've made. I can't really try all combinations, so I can't say which one works for sure. But directions I saved are not working, but if I set the same locations by hand and if don't chose the saved locations that are proposed, it works. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#583 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ATuvABdBIE_cnAVU89fjOhpvxOLgJe90ks5vPBvwgaJpZM4ansZJ>.

[ialokim]

Same issue for me since the update.
de.schildbach.pte.exception.BlockedException: https://api.navitia.io/v1/journeys?from=stop_area%3AOIF%3ASA%3A8775863&to=stop_area%3AOIF%3ASA%3A8739100&datetime=20190219T090456&datetime_represents=departure&min_nb_journeys=6&depth=0&walking_speed=1.12

@jeanrjc Where did you get this error from? This url lacks the coverage part, which causes the BlockedException (see Navitia playground). But you are right, after adding the coverage, Navitia returns an invalid_object error (see here).

So there are really two separate issues here:

• PTE is calling an invalid url (apparently only for unknown objects / only for this provider?)
• The station IDs changed at Navitia's side which is tracked in No connections found: Handle changes of location IDs #207.

[jeanrjc]

It's the exception I copied from the app, as in the screenshot above.
I think it is similar to #207 although I don't have full comprehension on the matter.

[ialokim]

@grote While investigating, I noticed AbstractNavitiaProvider does always call the Navitia API for journeys without specifying a coverage. Is that intended behavior? It seems this results in the BlockedException instead of returning an invalid_object on Navitia's side (see the two links to Navitia playground above).

Adding the coverage part would at least prevent this strange error and instead result in a (slightly better understandable) "invalid ID" error for the user.

[grote]

I'd say it should use the coverage in its requests, but I didn't write this provider, so I am not the authority here. How is this even working without specifying the coverage?

[El-Gavy]

I have the same issue, here is a screenshot in case it can help :

[ialokim]

This issue is fixed upstream.