Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Web API crashes when there's a variable's period mismatch #916

Open
sandcha opened this issue Nov 26, 2019 · 5 comments
Open

Web API crashes when there's a variable's period mismatch #916

sandcha opened this issue Nov 26, 2019 · 5 comments
Assignees
@HAEKADI
Labels
kind:fix Bugs are defects and failure demand.

Comments

@sandcha
Copy link
Collaborator

sandcha commented Nov 26, 2019 •
edited
Loading

Hi there!

I really enjoy OpenFisca, but I recently encountered an issue.

Here is what I did:

I sent a json situation to /calculate Web API endpoint.
I used openfisca_france v48.9.2 module and, in a Famille entity, I asked for:

        "prestations_familiales": {
            "2019-01": null
        },

Here is what I expected to happen:

Code 400 for ERROR: BAD REQUEST with something like:

{
  "familles": {
    "famille_1": {
      "prestations_familiales": "ValueError: Unable to compute variable 'prestations_familiales' for period 2019-01: 'prestations_familiales' must be computed for a whole year."
    }
  }
}

As we get this type of response when there is an entity mismatch (when we ask for a variable value in the wrong entity section).

Here is what actually happened:

🙀 Code 500 for Error: Internal Server Error and:

<html>
  <head>
    <title>Internal Server Error</title>
  </head>
  <body>
    <h1><p>Internal Server Error</p></h1>
    
  </body>
</html>

Here is data (or links to it) that can help you reproduce this issue:

{
    "individus": {
      "Claude": {
        "date_naissance": {
            "ETERNITY": "1977-05-14"
        },
        "salaire_imposable": {
          "2019": 24000
        }
      },
      "Camille": {
        "date_naissance": {
            "ETERNITY": "1978-10-11"
        },
        "salaire_imposable": {
          "2019": 23000
        }
      },
      "Bébé": {
        "date_naissance": {
            "ETERNITY": "2019-08-23"
        }
      }
    },
    "menages": {
      "menage_1": {
        "personne_de_reference": [
          "Claude"
        ],
        "conjoint": [
          "Camille"
        ],
        "enfants": [
          "Bébé"
        ],
        "loyer": {
            "2019-01": "1000"
        },
        "statut_occupation_logement": {
            "2019-01": 4
        },
        "revenu_disponible": {
          "2019": null
        },
        "impots_directs": {
          "2019": null
        }
      }
    },
    "familles": {
      "famille_1": {
        "parents": [
          "Claude",
          "Camille"
        ],
        "enfants": [
          "Bébé"
        ],
        "prestations_familiales": {
            "2019-01": null
        }
      }
    },
    "foyers_fiscaux": {
      "foyer_fiscal_1": {
        "declarants": [
          "Claude",
          "Camille"
        ],
        "personnes_a_charge": [
          "Bébé"
        ]
      }
    }
}

Context

I identify more as a:

  • Developer (I create tools that use the existing OpenFisca code).
@bonjourmauko bonjourmauko added the kind:feat A feature request, a feature deprecation label Dec 10, 2019
@HAEKADI
Copy link
Contributor

HAEKADI commented Jul 20, 2021 •
edited
Loading

@sandcha It seems to me like part of this has been fixed in the PR #993.

Running this example now renders:
500 for Error: INTERNAL SERVER ERROR and:

{
  "error": "Internal server error: Unable to compute variable 'prestations_familiales' for period 2019-01: 'prestations_familiales' must be computed for a whole year. You can use the DIVIDE option to get an estimate of prestations_familiales by dividing the yearly value by 12, or change the requested period to 'period.this_year'."
}

Same goes for Trace.

@HAEKADI HAEKADI mentioned this issue Jul 23, 2021
Merged
@HAEKADI
Copy link
Contributor

HAEKADI commented Jul 28, 2021

@sandcha So far I have not found a way to intercept the ValueError as a 400 error instead of a 500.
Since the ValueError raised is built-in, I could not find a way of introspecting it here.

So far the 500 internal error explains the origin of the error but does not imply it's a user error.

I believe one way to correct it would be to define a new error class, to substitute the built-in ValueError, that can be intercepted and introspected.

@HAEKADI HAEKADI self-assigned this Jul 28, 2021
@bonjourmauko bonjourmauko added kind:fix Bugs are defects and failure demand. and removed kind:feat A feature request, a feature deprecation labels Jul 28, 2021
@bonjourmauko bonjourmauko changed the title Getting an internal server error on Web API at period mismatch Web API crashes when there's a variable's period mismatch Jul 28, 2021
@bonjourmauko
Copy link
Member

@sandcha It seems to me like part of this has been fixed in the PR #993.

Running this example now renders:
500 for Error: INTERNAL SERVER ERROR and:

{
  "error": "Internal server error: Unable to compute variable 'prestations_familiales' for period 2019-01: 'prestations_familiales' must be computed for a whole year. You can use the DIVIDE option to get an estimate of prestations_familiales by dividing the yearly value by 12, or change the requested period to 'period.this_year'."
}

Same goes for Trace.

Yes! #993 allows for proper "catch-all" handling: returning a 500 instead of just crashing.

@bonjourmauko
Copy link
Member

Hello @HAEKADI @sandcha has this been fixed by #1026 or you're still experiencing the error?

@HAEKADI
Copy link
Contributor

HAEKADI commented Jul 29, 2021 •
edited
Loading

Hello @maukoquiroga ! The issue here is that technically the error rendered should be a code 400, because it's a user error, instead of a 500 error. Getting a 500 Internal Server Error leads to believe that the error generated from the server which is not the case here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@HAEKADI HAEKADI

Labels
kind:fix Bugs are defects and failure demand.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@bonjourmauko @sandcha @HAEKADI