Create a dataclass for indexer worker TaskStatus

[akshay-km]

Fixes

Fixes #4534 by @stacimc

Description

This PR adds a dataclass with type hints for each field for index worker task status. The task status was stored as dictionary before.

Testing Instructions

just build && just up

Use elasticvue to Delete All Documents from one of your existing indices. Eg: audio-init-filtered. The index should now have 0 documents.

Now run just catalog/shell, and you should be able to curl the indexer worker.

Replace the target_index name if you don't have audio-init-filtered
Note the start_id/end_id we're using, to make it reindex only 100 records
curl -X POST -d '{"model_name": "audio", "table_name": "audio", "start_id": 0, "end_id": 100, "target_index": "audio-init-filtered"}' -H "Content-Type: application/json" 'http://catalog_indexer_worker:8003/task'

You should get back a response like:

{
"message": "Successfully scheduled task.",
"task_id": "acfb9919708c4ef2a505fe5f8c6a10a8",
"status_check": "http://catalog_indexer_worker:8003/task/acfb9919708c4ef2a505fe5f8c6a10a8"
}

Now curl the status_check endpoint that was just returned:

curl 'http://catalog_indexer_worker:8003/task/acfb9919708c4ef2a505fe5f8c6a10a8
And you should see something like:

{
"task_id": "acfb9919708c4ef2a505fe5f8c6a10a8",
"active": false,
"model": "audio",
"target_index": "audio-init-filtered",
"progress": 100.0,
"start_time": "2024-07-04 18:56:28.288367",
"finish_time": "2024-07-04 18:56:28.384862",
"error": false
}

Which is similar to the response returned before adding dataclass for the task status.

Checklist

• My pull request has a descriptive title (not a vague title likeUpdate index.md).
• My pull request targets the default branch of the repository (main) or a parent feature branch.
• My commit messages follow best practices.
• My code follows the established code style of the repository.
• I added or updated tests for the changes I made (if applicable).
• I added or updated documentation (if applicable).
• I tried running the project locally and verified that there are no visible errors.
• I ran the DAG documentation generator (./ov just catalog/generate-docs for catalog
  PRs) or the media properties generator (./ov just catalog/generate-docs media-props
  for the catalog or ./ov just api/generate-docs for the API) where applicable.

Developer Certificate of Origin

Developer Certificate of Origin

Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.


Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

[krysal]

Hey @akshay-km, thanks for your help with this. In general, it looks good to me! You have a small failure in CI due to linting; it should be fixed once you run ./ov just lint and commit the changes.

Also, I'm unsure if @stacimc would want the active variable to have more direct access from the dataclass. Let's see what she was thinking about it.

[krysal]

The types can be more precise here. Below, the times are passed to the _time_fmt function that accepts integers, and probably progress is also an integer; @stacimc can confirm.

Suggested change

	task: Any
	start_time: Any
	model: str
	target_index: str
	finish_time: Any
	progress: Any
	task: Any
	start_time: int
	model: str
	target_index: str
	finish_time: int
	progress: Any

[akshay-km]

Hi @krysal , finish_time and progress has the same type: <class 'multiprocessing.sharedctypes.Synchronized'> .
But the value of progress in the api response is 100.0. So should it be set as a float ?

[stacimc]

float would be appropriate for the timestamps (and you can change the type of the timestamp parameter in _time_fmt to match, actually!)

progress and finish_time are shared variables using multiprocessing.Value so I believe the correct type would be Synchronized[float]

[akshay-km]

HI @stacimc When using Synchronized[float] , I am getting a TypeError: type 'Synchronized' is not subscriptable because Synchronized is not a type that can be parameterized in the typing module. So I have used Synchronized as type of progress and finish_time. Also used float as type for timestamps including for the parameter in _time_fmt_ function.
Have made a new commit with these changes.

[stacimc]

Oh, interesting! It looks like Synchronized is in the typeshed package/not available at runtime. I think the fix should be to add from __future__ import annotations to the top of the file.

[akshay-km]

Great!
Learned something new :)

[krysal]

More accurate:

[krysal]

@akshay-km I noted and applied the @stacimc's suggestion so this looks good to me! Thanks for you help.

Edir: also great job including complete testing instructions. It's appreciated :)

[akshay-km]

@akshay-km I noted and applied the @stacimc's suggestion so this looks good to me! Thanks for you help.

Edir: also great job including complete testing instructions. It's appreciated :)

Thanks @krysal

[openverse-bot]

Based on the contributor urgency of this PR, the following reviewers are being gently reminded to review this PR:

@stacimc
This reminder is being automatically generated due to the urgency configuration.

Excluding weekend¹ days, this PR was ready for review 10 day(s) ago. PRs labelled with contributor urgency are expected to be reviewed within 3 weekday(s)².

@akshay-km, if this PR is not ready for a review, please draft it to prevent reviewers from getting further unnecessary pings.

Footnotes

1. Specifically, Saturday and Sunday. ↩

2. For the purpose of these reminders we treat Monday - Friday as weekdays. Please note that the operation that generates these reminders runs at midnight UTC on Monday - Friday. This means that depending on your timezone, you may be pinged outside of the expected range. ↩

[stacimc]

Fantastic, thanks @akshay-km!

[akshay-km]

Happy to help :) Thanks for the feedback.