Cron Workflows UI Fails to Load

[dhpollack]

Pre-requisites

• I have double-checked my configuration
• I have tested with the :latest image tag (i.e. quay.io/argoproj/workflow-controller:latest) and can confirm the issue still exists on :latest. If not, I have explained why, in detail, in my description below.
• I have searched existing issues and could not find a match for this bug
• I'd like to contribute the fix myself (see contributing guide)

What happened? What did you expect to happen?

What Happened?

When we upgraded from argo workflows 3.5.5 to argo 3.6.2, the Cron Workflows tab errors with a "e.spec.schedules is undefined" error (see screenshot below). This only happens in namespaces that had cron workflows created before the upgrade. If a namespace did not have any previous cron workflows, then creating a new workflow works and is properly displayed.

I should say that it seems like the workflow does not display correctly in the UI. It still exists and runs as scheduled.

What did I expect to happen?

I would think that the UI would work with the old workflows and that I wouldn't have to re-create all our previous cron workflows in order to see them in the UI.

Version(s)

3.6.2

Paste a minimal workflow that reproduces the issue. We must be able to run the workflow; don't enter a workflow that uses private images.

This is a workflow server issue.  I assume creating any workflow with a schedule on 3.5.* and then upgrading to 3.6.2 would have this problem

Logs from the workflow controller

This is not a workflow controller issue.  I checked the workflow server and there were no errors.  It seems like it could be something with the frontend.  Below is the workflows-server logs:


time="2024-12-16T14:52:50.141Z" level=info msg="finished unary call with code OK" grpc.code=OK grpc.method=GetInfo grpc.service=info.InfoService grpc.start_time="2024-12-16T14:52:50Z" grpc.time_ms=0.118 span.kind=server system=grpc
time="2024-12-16T14:52:50.141Z" level=info duration="579.449µs" method=GET path=/api/v1/info size=951 status=0
time="2024-12-16T14:52:50.141Z" level=info msg="finished unary call with code OK" grpc.code=OK grpc.method=GetUserInfo grpc.service=info.InfoService grpc.start_time="2024-12-16T14:52:50Z" grpc.time_ms=0.113 span.kind=server system=grpc
time="2024-12-16T14:52:50.141Z" level=info duration="574.085µs" method=GET path=/api/v1/userinfo size=216 status=0
time="2024-12-16T14:52:50.149Z" level=info msg="finished unary call with code OK" grpc.code=OK grpc.method=ListCronWorkflows grpc.service=cronworkflow.CronWorkflowService grpc.start_time="2024-12-16T14:52:50Z" grpc.time_ms=8.589 span.kind=server system=grpc
time="2024-12-16T14:52:50.150Z" level=info duration=9.403989ms method=GET path=/api/v1/cron-workflows/data-science-stg size=12928 status=0
time="2024-12-16T14:52:50.240Z" level=info msg="finished unary call with code OK" grpc.code=OK grpc.method=GetVersion grpc.service=info.InfoService grpc.start_time="2024-12-16T14:52:50Z" grpc.time_ms=0.113 span.kind=server system=grpc
time="2024-12-16T14:52:50.240Z" level=info duration="508.15µs" method=GET path=/api/v1/version size=215 status=0

### Logs from in your workflow's wait container

```text
Again, this is a frontend issue, so it does not relate to the wait container.

[tooptoop4]

can u try with #13856

[dhpollack]

That seems like all the workflows won't render at all

[dhpollack]

But if I were to try this, is there a pre-built image or would I have to build it myself?

[tooptoop4]

build yourself

[dhpollack]

We ended up updating the CRDs on the cluster (previously had only updated the image tags) and deleting a few old cron workflows and suddenly the UI started working again.

[shuangkun]

It seems to be related to the fact that schedule was abandoned in 3.6 and replaced by schedules. https://argo-workflows.readthedocs.io/en/latest/deprecations/#cronworkflow-schedule

[Joibel]

'schedule' still works in 3.6, but is marked deprecated. Both 'schedule' and 'schedules' work.

[tooptoop4]

@shuangkun is correct, the UI code only handles schedules, not schedule

[MasonM]

#14047 sounds like the same issue. I mentioned in that issue that this can happen if you have a CronWorkflow that doesn't specify either a schedule or schedules field, but I don't know how that could happen. This command should tell you if that's the case:

kubectl get cronworkflow  -o json | jq -r '.items[] | select(.spec | has("schedule") or has("schedules") | not)'

[MasonM]

I confirmed the UI code handles both schedule and schedules. I think we need someone to run the command I gave earlier, or provide a full stack trace.