fix: Pass back real result for single task chains

[maybe-sybr]

Description

When chains are delayed, they are first frozen as part of preparation
which causes the sub-tasks to also be frozen. Afterward, the final (0th
since we reverse the tasks/result order when freezing) result object
from the freezing process would be passed back to the caller. This
caused problems in signaling completion of groups contained in chains
because the group relies on a promise which is fulfilled by a barrier
linked to each of its applied subtasks. By constructing two
GroupResult objects (one during freezing, one when the chain sub-tasks
are applied), this resulted in there being two promises; only one of
which would actually be fulfilled by the group subtasks.

This change ensures that in the special case where a chain has a single
task, we pass back the result object constructed when the task was
actually applied. When that single child is a group which does not get
unrolled (ie. contains more than one child itself), this ensures that we
pass back a GroupResult object which will actually be fulfilled. The
caller can then await the result confidently!

[maybe-sybr]

This change is the one I mentioned I would pull out of #6354 - FYI @auvipy . I believe the changeset here will also address your coverage comment on that PR.

[maybe-sybr]

Ah, I need to pull one of the integrations tests across from that PR as well. This is the change that makes it not time out!

[lgtm-com]

This pull request fixes 1 alert when merging 8b4250d into 735f167 - view on LGTM.com

fixed alerts:

• 1 for Module is imported with 'import' and 'import from'

[thedrow]

Can we add an integration test for this?

[maybe-sybr]

Can we add an integration test for this?

Yep, test_nested_chain_group_lone() is the one which demonstrates the fix. The other is just a sanity check for simple groups since there wasn't one in the suite.

[lgtm-com]

This pull request introduces 1 alert when merging f0242da into 735f167 - view on LGTM.com

new alerts:

• 1 for Non-exception in 'except' clause

[auvipy]

apart from the better naming, looks good

[maybe-sybr]

I went with result_from_apply and also changed the results returned from self.prepare_steps() to be results_from_prepare. That should make it more obvious, and with the block comment explaining why we should return the one _from_apply I think it's nice and readable :)

[maybe-sybr]

Thanks @auvipy and @thedrow :)

[lgtm-com]

This pull request introduces 1 alert when merging bd6c6bd into 735f167 - view on LGTM.com

new alerts:

• 1 for Non-exception in 'except' clause