Skip to content

Perseus export of a legacy input question with an overflowing numeric answer ships invalid JSON #6232

Description

@rtibblesbot

❌ This issue is not open for contribution. Visit Contributing guidelines to learn about the contributing process and how to find suitable issues.

Observed behavior

PerseusExerciseGenerator._process_input_answers keeps any answer whose extract_value(...) is truthy. extract_value("1e400") is inf (-1e400 → -inf; a 401-digit integer → inf; an inf/inf fraction → nan), so the perseus/input_question.json template renders "value": inf.

This applies to legacy INPUT_QUESTION items. #6231 gates native QTI text-entry items out of derivation but does not touch this path.

Errors and logs

json.loads on the rendered item raises JSONDecodeError.

Expected behavior

Non-finite answers are dropped, like other unparseable answers, so the item JSON is valid.

User-facing consequences

Older Kolibri cannot load the item JSON, so learners get no exercise for the node.

Steps to reproduce

  1. Build an INPUT_QUESTION item with answer "1e400".
  2. Run _process_input_answers, then render_to_string("perseus/input_question.json", ...).
  3. json.loads on the output fails on "value": inf.

Context

Activity

  1. added theissue type on Sep 30, 2026
  2. self-assigned this
    on Sep 30, 2026
  3. rtibblesbot commented on Sep 30, 2026

    @rtibblesbot
    ContributorAuthor

    Plan: PerseusExerciseGenerator drops INPUT_QUESTION answers whose parsed value is inf/-inf/nan, so the rendered item JSON is valid.

    • Drop non-finite input answers
    • Simplify pass

    Assumptions — the issue did not settle these; say so if one is wrong.

    • Filter in _process_input_answers, not parse_valid_number; if the parser should own it, move the check there and add a test_parser.py case.
    • Dropping every answer of an item (all non-finite) still publishes the item with no answers; if it should be skipped or flagged, that is a separate change.

    @rtibblesbot's comments are generated by an LLM, and should be evaluated accordingly

    How was this generated?
    • Implemented code following the pre-approved plan using test-driven development (red-green-refactor)
    • Ran the project's full test suite and linter before committing
    • For UI changes: captured live screenshots to verify rendering
    • For backend changes: verified with example API/CLI output
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions