The rule '0' of answer group '0' having rule type 'IsWithinTolerance' have 'tol' value less than or equal to zero in NumericInput interaction.

[kevintab95]

This error occurred recently in production:

Traceback (most recent call last):
  File "/workspace/core/controllers/editor.py", line 1478, in put
    exp_services.create_or_update_draft(
  File "/workspace/core/domain/exp_services.py", line 3122, in create_or_update_draft
    updated_exploration.validate(strict=False)
  File "/workspace/core/domain/exp_domain.py", line 1702, in validate
    state.validate(
  File "/workspace/core/domain/state_domain.py", line 3741, in validate
    self.interaction.validate(
  File "/workspace/core/domain/state_domain.py", line 2054, in validate
    interaction_id_to_strict_validation_func[self.id](strict)
  File "/workspace/core/domain/state_domain.py", line 1204, in _validate_numeric_input
    raise utils.ValidationError(
core.utils.ValidationError: The rule '0' of answer group '0' having rule type 'IsWithinTolerance' have 'tol' value less than or equal to zero in NumericInput interaction.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/layers/google.python.pip/pip/lib/python3.8/site-packages/webapp2.py", line 604, in dispatch
    return method(*args, **kwargs)
  File "/workspace/core/controllers/acl_decorators.py", line 2133, in test_can_save
    return handler(self, exploration_id, **kwargs)
  File "/workspace/core/controllers/editor.py", line 1487, in put
    raise self.InvalidInputException(e)
core.controllers.base.UserFacingExceptions.InvalidInputException: The rule '0' of answer group '0' having rule type 'IsWithinTolerance' have 'tol' value less than or equal to zero in NumericInput interaction.

Where did the error occur? Add the page the error occurred on. Editor page when saving draft.

Frequency of occurrence Add details about how many times the error occurred within a given time period (e.g. the last week, the last 30 days, etc.). This helps issue triagers establish severity. 12 times in 9 days.

General instructions for contributors In general, the procedure for fixing server errors should be the following:

• Analyze the code in the file where the error occurred and come up with a hypothesis for the reason.
• Based on your hypothesis, determine a list of steps that reliably reproduce the issue (or confirm any repro instructions that have been provided). For example, if your hypothesis is that the issue arises due to a delay in a response from the backend server, try to change the code so that the backend server always has a delay, and see if the error then shows up 100% of the time on your local machine.
• Explain your proposed fix, the logic behind it, and any other findings/context you have on this thread. You can also link to a debugging doc if you prefer.
• Get your approach validated by an Oppia team member.
• Make a PR that fixes the issue.

[seanlip]

Note: we should be catching this validation for NumericInput rules in the frontend instead, and display it as an error that prevents saving.

[manangoel99]

@seanlip could I pick this up?

[seanlip]

Hi @manangoel99, per the guidance at https://github.com/oppia/oppia/wiki/Contributing-code-to-Oppia#choosing-a-good-first-issue, please provide an explanation of what your PR will do (with names of files you're changing, what you plan to change in each file, etc.). If it looks good, we can assign you to this issue.

Please also follow the other instructions on that wiki page if you have not yet done so. Thanks!

[arjen0203]

So I've been looking into this issue. The issue occurs each time within the creator dashboard when trying to safe a numeric value of type "is within" where the tolerence value is 0 or negative. The problem is that the user should not be allowed to try and save a tolerance value that is zero or negative and display a warning about this.

Also seems that this issue was supposed to have been fixed in version 3.2.9. See the related PR: 15983, however this has not been the case.

Currently looking into the method getAllWarnings from numeric-input-validation-service.ts where the code from the previously mentioned PR is located to see if I can use this like the way that it was intended during that PR.

Would be nice if I could be assigned this task, but also understand if rather not, since I have yet to find the actual fix to the issue.

[seanlip]

Thanks for the analysis @arjen0203 and for identifying the older PR! I suspect this means that we have data in the existing datastore that doesn't pass the validation checks. This will likely entail a data migration instead (since the code currently guards against new occurrences), which means that this probably isn't a starter issue after all, and you might want to pick up a different one instead.

Sorry for misidentifying this, I didn't realize that the issue was due to legacy server data but I suspect that this is more likely after reading your analysis. (I am assuming that you have tried to reproduce this as a user on your local dev server and found that it was not possible to enter a negative or 0 tolerance value -- is that correct?)

[arjen0203]

Yes, running the latest version locally, you'll get the error as mentioned at the start of this issue on the server side and as such won't be saved. I tried running an earlier version (3.2.5) and within that version negative values could be stored without issue, so there might indeed needs to be done some data migration.

So in short some data migration needs to be done to ensure when a creater used is within in the past they do not have a negative or 0 value for the tolerence stored. As well as the fronted needs to be updated to properly warn the user of the negative/zero tolerence value and not allow the user to try and save such a value.

I'll look for a different good first issue to pick up instead

[seanlip]

@arjen0203 Well actually -- one possible way to tackle at least part of this issue is to catch the error on the client side, so that it doesn't even make it to the server. It should be caught in the normal frontend validation checks. If that isn't done yet, do you want to have a go at it?