Handling of multiple NO_SERVICE disruptions on a vj

[eturck]

Hello.

After quickly discussing something with @kinnou02 we decided that it would be better to have an issue open on the subject.
We are actively using Chaos in production and there is one case which happened not long ago that navitia did not handled.

We have :

• A line A, with 5 stops S1/2/3/4/5.
• One disruption D1 with one line_section impact between S2 and S4, running from the 1st to the 30th.
• Another disruption D2 with one line_section impact between S3 and S4 running from the 15th to the 30th.

What is happening is, if D1 has been applied, D2 will never be applied. The validity_pattern of the original vjs will not intersect the impact's one, and the adapted vjs will not stop at S3 and S4 so will not be impacted (what is really happening is we look at the base stop_time so we see the adapted vj passing at those stops but the vp for those stops is empty). D2 is just ignored.
This has multiple effects :

• The original VJ is not link to D2's impact. If there is a message on this impact it will not be in traffic_report nor in disruption APIs.
• If D1 is deleted, D2 will not be applied until D2 is sent again or Kraken reload its disruptions from Chaos database.

It is not just a problem with line_section, if the full line is in NO_SERVICE state other stop_point / line / line_section disruptions will not be linked as long as their validity_pattern is completely included in the one from the first impact.

My guess is that if a base_vj should be impacted by a disruption we would need to "impact" the adapted_vj resulting from other disruptions impacting it, even if those adapted_vj are by themselves not really impacted. But I don't really realize the cost, the impact and the difficulty of this.

Let me know what you think.

Have a nice day :)

[eturck]

If you want to test this I suggest starting by using the fix of PR #2700. Otherwise it creates a all lot of other problems :D.

[pbougue]

By looking from afar, I agree both on problem and the possible approach.
No idea about the complexity of it.

Also, the solution has to work for adapted and realtime VJs.