Nutrition fact issues when exceptions occur

[NixedSec]

What

• When a user id/password exception occurs, whether this be when editing nutritional information, packaging information or something else; nutritional information fails to be displayed within the app. This also breaks the nutritional information page's "calculate" fragment, as during this time clicking the calculate button fails to do anything. All of these issues are remediated by clearing the exception.
• I believe, during this time the entered values are updated on the website. Why does these exceptions cause the app not to be able to gather any nutritional information from the server and act as though there is no data for these sections (Greying out the button for nutrition, displaying the "3 question" NOVA prompt and displaying no values within the nutrition information editing page)?

Steps to reproduce the behavior

1. Go to any product
2. Edit the product in a way to cause the exception to occur (Editing nutritional information, sometimes) (Editing packaging information, every time)
3. Go to product page
4. Notice the "answer 3 questions NOW" NOVA prompt
5. Click prompt, notice the 2nd Nutri-Score button is greyed out
6. Click the button, notice all information is empty
7. Return to the product page
8. Click "Nutrition facts", above "Ingredients"
9. Click the Calculate button, notice that nothing happens.
10. Go to the DEV mode menu, clear the Exception
11. Check the product page for the calculate, NOVA and nutrition information issues. Notice that they have gone.

Expected behavior

As we are able to gather information from the server whether we are logged in or not, this issue should not cause nutritional information to not be accessible from the app.

Why

• It breaks functionality

Part of

• Nutrition input issues #4627
• Invalid user id and password Exceptions #4637
• User is not alerted when a task fails #4638

Smartphone model

• Device: Pixel 6
• OS: Android 13
• App Version: 4.10.0+1230-ZXing-FDroid

[monsieurtanuki]

@NixedSec I have to have a look at it.
It may be because when we send data to the server we need to somehow change the data locally immediately, and in some cases the fields we populate for the server update and the fields we populate for the local update are different. And if something goes wrong in the local update, you have the impression that the local data is wrong, while the data is up-to-date on the server.

[g123k]

I wonder if, for the fast track, we shouldn't use blocking requests to prevent this weird asynchronous change.
Another option is to explain that actually it can take a few seconds.