Cant navigate back to overview from slug pages

[jstet]

Repro:

1. Go to https://www.correlaid.org/daten-nutzen/projektdatenbank/
2. Click on read more for Mitgliederbefragung des Turnvereins Käfertal
3. try to navigate back

url changes but page content doesnt

Same for clicking on blogposts

[KonradUdoHannes]

This sounds to me like our typical runtime error where a bug in our code causes a svelte framework promise to fail at runtime. Aside from the non-closing navigation menus this behaved the same. We can check it by simply checking the browser console for the failed promise. This will not immediately identify the underlying cause but will narrow the problem a bit.

[jstet]

I dont see anything in the console though :'(

[jstet]

I actually noticed this bug also applies to events and blog posts

[jstet]

• https://github.com/sveltejs/kit/issues/9832 @KonradUdoHannes spent some time trying to solve this but wasnt succesful. any ideas?

[KonradUdoHannes]

I'll have a look.

[KonradUdoHannes]

I don't have a solution yet, but it might be a good idea to collect some observations so here they are.

• the issue only exists when when using the back button from a slug page to the the corresponding list page, for example from [events]/[slug] to [events].
• The issue does not appear when creating a different browser history to a slug page and using the back button, for instance when starting hat / and navigating to a slug page by copying the url in the browsers navigation bar. In such a case the back button works as expected.
• When the browser history has consecutive slug pages from the same path, for instance different blog posts, the back button works.
• when reproducing the issue and changing the language after using the back button, i.e. after the url bar in the browser changed: In this case the language is changed for the slug page! So even though the browser might have been at /veranstaltungen it will then jump to en/events/[some event slug]. This is quite interesting because it suggests that some internal state is not updated as expected when using the back button. Maybe there is an issue related to oure $page_key store logic as slug pages share the stored value with their parents.
• I also started to look more into reactivity and whether the issue is related to this and the fact that components get reused as much as possible. So far I checkd the load statements systematically and it appears that their results get cached quite a bit such that the don't rerun when the back button is used, both in cases in which the back button works and in cases in which it doesn't. So the data object won't trigger reactivity and one could look more into other parts, such as url changes that might trigger it.

[jstet]

Thank you Konrad! I think it is also worth mentioning that going back to the overview worked in the past.

[KonradUdoHannes]

That is also quite interesting. With that the two most promising approaches for further investigation I see are the following.

1. Deploy local dev versions of old commits in order to find one where the back button was still working. Then either user git diff to determine the change that causes the issue, or try to progress forward as much as possible in the commit history until the issue appears again. The disadvantage of this approach ist that we cannot roll back the CMS, and some current CMS schemas might not match the expectations of the older website implementations. But since we can use any of the slug pages, one might be stable enough.
2. Look more closely into the logic of the change language button and which states it relies on, as these states are apparently the ones that are not properly updated when the issue appears.

[KonradUdoHannes]

I was able to use method 1 to identify the commit that broke it. The commit is 4f6127531e42fac989fc1fa24f4e68cbd5aca171 It is part of the filter implementation when url mutations without navigation where introduced, so I also think it makes sense that this might cause such a bug. I havn't looked into the commit yet, but I think this should bring us quite a bit closer to fixing the issue.

[jstet]

Yes thats makes a lot of sense. I will try to fix it this evening.