feat(ai_eff): AI Effort Prediction API changes

[SteveDala]

Background and Context

Currently, the task definition object contained a weighting field which, when populated, assisted students in understanding how much of their unit they had completed by finishing the task. This measure is implemented in a visualisation called the Progress Burndown Chart:

Unfortunately, weighting is not always filled out accurately or at all by tutors when creating task definitions. This leads to the chart feeling bad for students by way of inconsistency; sometimes submitting a Pass task reduces this Burndown chart by the same amount that a Distinction task does, even if much more effort was put into the distinction task.

The AI effort prediction feature aims to solve this task effort evaluation with an intelligent regressor trained on data from previous Task Definitions in OnTrack.

Description

This pull request introduces the necessary API changes to introduce intelligent effort prediction of tasks to OnTrack.

• changes the weighting field throughout the repo to estimated_hours to give meaning to the integer value in the task definition
• introduces the predicted_effort field to store the effort predicted by the intelligent regressor service.
• introduces a new Sidekiq job definition to send prediction jobs to the intelligent regressor service, available from the /api/units/:unit_id/task_definitions/:task_def_id/predict_effort endpoint

Type of change

Please delete options that are not relevant.

• New feature (non-breaking change which adds functionality)
• This change requires a documentation update

Dependencies

This PR has no additional dependencies on its own. To test the integration with the intelligent regressor service, the doubtfire-effort-predict service will need to be available at ML_SERVICE_URL (if configured from the superproject, this will be http://effort-predictor:8080/)

How Has This Been Tested?

If the ML service is running and the ML_SERVICE_URL is defined (easiest setup is to use the superproject in VSCode dev containers), the API can be tested from either the OpenAPI doc page /api/docs or from the rails c console.

Test A

Open localhost:3000/api/docs, send this payload to the /api/auth endpoint:

{
  "username": "aadmin",
  "password": "password"
}

Retrieve the auth_token from the response and note it down. Then, send these parameters (or any alternative that matches unit_id with task_def_id) to the /api/units/:unit_id/task_definitions/:task_def_id/predict_effort endpoint:

• unit_id: 1
• task_def_id: 1
• Username: aadmin
• Auth_Token: (your noted auth token)

When the response gives a Sidekiq job_id, note that ID down. Then send it as a parameter to the /api/sidekiq/{id} endpoint:

• id: (your noted Sidekiq ID)
• Username: aadmin
• Auth_Token: (your noted auth token)

You should receive a response like the following:

{
  "id": (Sidekiq ID),
  "status": "complete",
  "pct_complete": null,
  "message": null,
  "processed_count": null,
  "total_count": null,
  "created_at": null,
  "updated_at": (Unix timestamp),
  "job_class": "PredictEffortJob",
  "result": "{\"predicted_effort\" => (The predicted effort value from the service)}"
}

Test B

Open Rails console (rails c from the root of the API repo inside the container).

Use the following commands to perform a job and get it's status:

jid = PredictEffortJob.perform_async(2, 1) # where 2 = task_def_id, 1 = user_id
Sidekiq::Status.get_all(jid)

Use the following commands to check the predicted_effort and estimated_hours field sagainst task_def_id = 2:

task = TaskDefinition.find_by(id: 2)
[task&.predicted_effort, task&.estimated_hours]

The effort value should match from the above Sidekiq job status.

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation if appropriate
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• I have created or extended unit tests to address my new additions
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[jtalev]

Looks good!

[officialid130-13e13]

I have reviewed the changes and the FastAPI/Sidekiq refactor looks good overall.
The CI build is failing during the TeXLive image build. This is the same issue I hit earlier — the pdfmanagement-testphase package is no longer available. Can you please remove pdfmanagement-testphase from the install list in the texlive-builder Dockerfile. After removing that package, the build should pass again.