Ensure we have a better behavior when the server is down

[teolemon]

What

We should better handle if any of the backend servers are offline.

[lakshaydewan]

@teolemon would love to work on this.

[KarruHarin]

@teolemon Is there way to reproduce the error or server crash , I am unable to recreate it just based on the image .

[VaiTon]

@teolemon Is there way to reproduce the error or server crash , I am unable to recreate it just based on the image .

Disable your internet access and try to open the dev server web page

[github-throwaway]

@akashshetty1997 could you check if this is still relevant? Thanks.

[akashshetty1997]

sure @github-throwaway i will look into it.

[akashshetty1997]

Currently, when you disable your internet access and try to open the dev server webpage, this is the behavior you’ll see:

https://github.com/user-attachments/assets/be139526-3ac7-409e-94d2-20e510ffbb8a

Do you think we should show a user-friendly error message like the example below?

@VaiTon @github-throwaway

[github-throwaway]

Your video does not play for me. Could post a screenshot?

[akashshetty1997]

1. If the internet is off and I try to run the project, the server closes automatically and throws the following error:

2. However, if I keep the internet on, let the project fully load, and then turn off the internet, the following behavior is observed instead:

@github-throwaway

[github-throwaway]

We should handle that more gracefully. Both cases. We should also handle the case of the backend / API is unavailable for the deployed frontend.

[akashshetty1997]

@github-throwaway What’s the best way for us to handle backend/API unavailability on the frontend in a clean, user-friendly way? Should we go with a full error page or just show fallback components? Also wondering how we can make sure we're covering things like try/catch around API calls, global error handling, retry logic, and offline detection.

[github-throwaway]

Show something like "Backend Server unavailable" and a link to the status page. We could show cached data but without the backend the front end is somewhat useless. You can implement a retry with exponential back off, if you want to. But I would start simple and iterate.

[akashshetty1997]

cool, makes sense to start simple. quick question Do we already have a status page I should link to, or should I just leave that as a placeholder for now?

[github-throwaway]

https://status.openfoodfacts.org/

[akashshetty1997]

@github-throwaway @VaiTon Could you please check if this is what we were aiming to achieve?

Changes I Madet:

src/routes/+page.ts:

• Better Error Handling: I wrapped the data fetching in a try...catch block to handle any issues that pop up during API calls.
• Network Error Detection: Added logic to detect when there’s no internet or if the server can’t be reached.
• Proper SvelteKit Error Throwing: Used throw error() from @sveltejs/kit, so SvelteKit knows exactly how to handle and display the error.
• Structured Errors: Made sure the error details passed to throw error() are in the right format for SvelteKit.

src/routes/+error.svelte:

• Error Message Display: Set it up to show clear error messages.
• Added Translations: Included error messages in both en.json and it.json for better localization.

"errors": {
  "network": {
    "title": "Connection Error"
  }
}

https://github.com/user-attachments/assets/b9004f02-44e4-46c1-8b28-c96259f17cf5

[VaiTon]

@akashshetty1997 seems good, but I can't view the video (please use MP4)

[akashshetty1997]

@VaiTon can you view it now?

https://github.com/user-attachments/assets/ff2edf75-ecb3-4bec-be00-c252f3d61b3f

[VaiTon]

Seems good!