editoast: updating a track section doesn't refresh osrd_search_signal

[leovalais]

What happened?

Some info about the track section of a signal are duplicated in osrd_search_signal but there is no trigger on osrd_infra_tracksectionmodel that actualizes the search cache when a track section is updated.

More generally, the way cache refresh for search tables works is very unsatisfactory. Insert/update riggers and cache update logic are not dissociated, there is no way to deal with such dependency problems (besides creating the triggers manually) and the whole thing is not very robust.

What did you expect to happen?

Any update of a track section should be reflected in osrd_search_signal automatically.

How can we reproduce it (as minimally and precisely as possible)?

1. Select a signal in osrd_search_signal
2. Change the line name of its track section in osrd_infra_tracksectionmodel
3. Back in osrd_search_signal, the line name is not updated

What operating system, browser and environment are you using?

N/A

OSRD version (top right corner Account button > Informations)

dev

[leovalais]

Update: the bug is still here, doing well...

To rephrase the description, the bug comes from the cache search_signal not being updated upon modification of a track section. search_signal has two track-section related fields: line_code and line_name (which are used in the ui).

If we change the line name of a track section with a signal S on it, the search_signal entry for S will still use the old line name. It also happens for line codes.

There's several ways to fix this, but none are exactly trivial.

1. Have an incremental computation-compatible representation of an infrastructure in which we also include the cache entries as being infra objects. We then let the change propagation chain take care of updating the entry. This architecture is desirable for editoast for many other reasons, but this is a very large amount of work.
2. Aggressively wipe the cache for all objects of the infra being edited like we do for layers. Definitely less work, but will increase the latency of the edition (which is already not great for real infrastructures).
3. Write a specific trigger on infra_object_track_section to handle this case. This is cumbersome to write, even more to maintain, and doesn't solve the problem we have with the search engine but just circumvents it.

Probably a wontfix kind of bug tbh (at least until we have incremental computation).