fix: return failed instead of success when no container status

[shuangkun]

We have a product named ManagedArgoWorkflows in AlibabaCloud use eci (virtual-kubelet).
Sometimes the pod failed for some reason (no stock、timeout、schedulerFailed and more than these)，in these conditions, the pod mightly not has containerstatus/condations/messages, and then the pod will marked success and caused mistake.

So I think we should return failed when the pod is Failed and we can't find message and status in the pod.

Maybe this problem will also occur in other public cloud platforms.

[Joibel]

This feels like a very dangerous assumption to make. How do we know that the status won't get updated later to something more successful?

[shuangkun]

This feels like a very dangerous assumption to make. How do we know that the status won't get updated later to something more successful?

I think if it get update later from failed to successeed. the workflow will reconicle. if the pod failed, it may be retry. if it marked successed(but actually never run )，we made a mistake. This is what I encountered

[shuangkun]

This feels like a very dangerous assumption to make. How do we know that the status won't get updated later to something more successful?

I think in function "inferFailedReason", we are more likely retune failed instead of successed if we really didn't got the fail reason.

[Joibel]

Ok, I follow your reasoning now and why this is a reasonable change.

[Joibel]

Thanks, looks good to me.