_Exception: Exception: Could not add price: {"proof":["Proof does not belong to the current user. Adding a pr...

[sentry-io]

Sentry Issue: SMOOTHIE-560

_Exception: Exception: Could not add price: {"proof":["Proof does not belong to the current user. Adding a price to a proof a user does not own is only allowed for {proof_constants.TYPE_ALLOW_ANY_USER_PRICE_ADD_LIST} proofs"]}
  File "stacktrace_utils.dart", line 10, in getCurrentStackTrace
  File "sentry_exception_factory.dart", line 44, in SentryExceptionFactory.getSentryException
  File "sentry_client.dart", line 235, in SentryClient._prepareEvent
  File "sentry_client.dart", line 119, in SentryClient.captureEvent
  File "hub.dart", line 173, in Hub.captureException

[monsieurtanuki]

cc @raphodn @raphael0202
Probably related to #6061

[monsieurtanuki]

Top 3 sentry error this week.

[raphael0202]

The front-end keeps trying to send the price even if we return an HTTP 4XX, right?
When looking at "all events" (https://openfoodfacts.sentry.io/issues/6119899378/events/?cursor=0%3A100%3A1&project=5376745&referrer=github_integration), it looks like many errors are associated to the same client, in a row.

[monsieurtanuki]

@raphael0202 And that will go on forever, as we don't have a way in Smoothie to say: "hey, eventually we haven't done what you asked". We just keep trying.
Maybe in 2025?

[raphael0202]

And that will go on forever, as we don't have a way in Smoothie to say: "hey, eventually we haven't done what you asked". We just keep trying.

In my opinion, the front-end should drop the task if the server returns an HTTP 4XX. We should only keep trying again if it's a 5XX.

[monsieurtanuki]

In my opinion, the front-end should drop the task if the server returns an HTTP 4XX. We should only keep trying again if it's a 5XX.

The user assumes that the (background) task will eventually be processed; that's what we're selling anyway.
After a couple of years and many many comments, I still wasn't able to plead for a decent UX feedback when a background task is obviously wrong and should be terminated. Maybe with your help...

[raphael0202]

The user assumes that the (background) task will eventually be processed; that's what we're selling anyway.

Yes, but sending incorrect (as expected by the API) requests forever is not an option. Stopping to perform these requests is more important (in my opinion).

[monsieurtanuki]

Yes, but sending incorrect (as expected by the API) requests forever is not an option. Stopping to perform these requests is more important (in my opinion).

Makes sense. But:

1. should we warn the user, and if yes, how?
2. how should we detect those failing tasks? Just by assuming that a task that fails n times, and not for obvious internet connection/server 5xx errors, is to be automatically canceled? (even more acceptable if we warn the user, cf. 1)