hub: a task without subtaks may show an incorrect number of them about openscanhub HOT 13 CLOSED

@lzaoral asked me to illustrate this issue.

from openscanhub.

@psimovec has volunteered to handle the necessary kobo updates. (BTW, that kobo version also brings in the correct inheritance of task priorities.)

from openscanhub.

I am afraid you need to provide more details if you expect anybody else to take this. If you noted it for yourself to eventually get back to this, so be it.

from openscanhub.

The code that is responsible for updating of the subtask count field is the following method in kobo:
https://github.com/release-engineering/kobo/blob/986f2a305f9c675dbb54e34c91f09e443e328af3/kobo/hub/models.py#L598-L605

from openscanhub.

I believe it is quite clear that that number corresponds to the id of the task (red text added by me) because the newest value corresponds to the actual count of all tasks:

But I'm not sure why that happens, the code from kobo is quite explicit about using the correct value of the subtask_count property:

    def save(self, *args, **kwargs):
        # save to db to precalculate subtask counts and obtain an ID (on insert) for stdout and traceback
        super(self.__class__, self).save()
        self.subtask_count = self.subtasks().count()
        super(self.__class__, self).save()
        self.logs.save()
        if self.parent:
            self.parent.save(*args, **kwargs)

from openscanhub.

I've analysed tasks on the staging instance and the wrong values began appearing just when we migrated to RHEL 8 and Python 3.

from openscanhub.

I could not reproduce this locally until @kdudka suggested to use the same version of kobo as we use on the staging instance (Thanks a lot!). Something was fixed between master and the kobo-0.25.0 tag.

from openscanhub.

The issue was fixed in upstream kobo by release-engineering/kobo#185. Therefore, we should make sure to update kobo in EPEL to at least kobo-0.26.0. After that, I'll create a one-time migration to recompute subtask_count property for all tasks.

from openscanhub.

Nice. Thank you for tracking it down!

from openscanhub.

EPEL 8 kobo Bodhi update: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-1346547daa

from openscanhub.

@kdudka Is anything blocking this MR? It should not cause any disturbances unless the migration is executed.

from openscanhub.

@kdudka Is anything blocking this MR?

Nothing I know of. Did we test this on a staging instance?

It should not cause any disturbances unless the migration is executed.

True but migrations are executed automatically upon each update.

from openscanhub.

I've only tested this migration on my local instance with a restored database backup when I've originally created that MR.

from openscanhub.