Remove unused/non-useful fields from LLMFreeTextQuestionValidationResponse #728
+0
−66
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
markCalculationInstructions
has been unused for around a year and no longer exists in any content. It can be safely removed from the response DTO (and I also clean up the last remaining reference from theIsaacLLMFreeTextQuestion
object while at it).additionalMarkingInstructions
is still used, but exclusively for adding per-question detail to the LLM prompt. We don't use it in the front-end and have no reason to send it in this response.maxMarks
is still used, but is now sent in the question DTO to be displayed in the front-end early. We therefore don't need to send a duplicate in this response later.To note:
markBreakdown
currently includes all mark descriptions so that these can be displayed in the front-end markscheme. We don't want them sent earlier in order to prevent users from seeing the markscheme without first answering the question, but this leads to a lot of redundancy in the database. I see two possible solutions to this, but both more complicated than simply removing fields as above:I think that the most sensible solution is probably to keep it for now, but have it in mind in the future if we start having database storage issues.