#3267 Document API 'state' and 'waiting'
Closed: Fixed by tkopecek. Opened by siwalter.

I would like to understand what the different states mean in relation to waiting. I have grepped the source, but I am still unsure of how to treat a waiting task. Would it be possible to add something about this to the documentation?


Metadata Update from @tkopecek:
- Custom field Size adjusted to None
- Issue set to the milestone: 1.29
- Issue tagged with: doc

Metadata Update from @tkopecek:
- Issue set to the milestone: 1.28.1 (was: 1.29)

PR #3292

Thanks Tomas! I had a look at the new documentation in the PR, and it explains much. That's very helpful.

Is there anything about 'waiting'? It seems to be a boolean that is independent of 'state'.

Ah, I'll add something there. Waiting simply means that task is blocked on some other task/subtask before it can continue. Typically parent task is waiting for all its children before completing.

Thank you so much. That's useful info.

I was having a discussion with another developer, and he said that it's possible for a task to be in 'canceled' state, and 'waiting'. In that case, would seem that a canceled task is waiting for it's children to clean up - for example. Does that sound correct?

In case you're interested: https://gitlab.com/testing-farm/gluetool-modules/-/blob/main/gluetool_modules/infrastructure/koji_fedora.py

Theoretically yes but I wonder if it makes a difference in any way for you? I'm curious abut such usecase. It shouldn't have any impact on the user. If task is closed/cancelled it is done. Nothing should impact it after that.

E.g. there are tasks which are "waiting" forever as they've been cancelled/failed. That value will never be updated (we can fix it for more clarity but there is no real impact).

OK, that makes sense. I take your word for it. I'll show this to my team. It will help us to code against koji better knowing more about it's behaviour. Thanks!

Commit ddd5f221 fixes this issue

Commit d6a02675 fixes this issue

Metadata Update from @jcupova:
- Issue tagged with: no_qe

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/koji/koji/issues/3267

Please continue any further discussion there.

Metadata
Related Pull Requests