Workflow Details page makes unnecessary Archived request

[ryancurrah]

Pre-requisites

• I have double-checked my configuration
• I can confirm the issue exists when I tested with :latest
• 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?

Users of Argo Workflows version 3.5.5 3.5 experience an issue where the Workflow Details page attempts to fetch workflows as if they were archived, even when the archived workflows feature is not utilized. This behavior results in an unnecessary API call, leading to the error message getting archived workflows not supported and potentially degrading the UI experience.

The issue manifests before the workflow details page loads, with the UI erroneously trying to retrieve an archived version of the workflow based on its UID.

Initial troubleshooting suggested setting the ARGO_ARTIFACT_SERVER environment variable to false as a potential fix. However, the error persisted on the workflow details page, and archived logs ceased to function after applying this workaround. edited by agilgur5: this is actually unrelated, see below comment.

Discussion on Slack highlighted a section of the frontend code responsible for this behavior, indicating that the UI checks for an archived workflow status unnecessarily. This check occurs even when archived workflows are not enabled, which should indicate that the workflow is not considered archived.

The conversation concluded with the suggestion to file a GitHub issue to track this problem, aiming for a more concise and efficient handling of workflow status checks in the UI to prevent unnecessary API calls and improve the user experience.

Potential Solutions:

1. Adjust the frontend code to ensure that archived workflow checks are only performed when necessary, based on the presence of appropriate configuration settings.

Version

v3.5.5

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

metadata:
  name: delightful-bear
  namespace: default
  labels:
    example: 'true'
spec:
  arguments:
    parameters:
      - name: message
        value: hello argo
  entrypoint: argosay
  templates:
    - name: argosay
      inputs:
        parameters:
          - name: message
            value: '{{workflow.parameters.message}}'
      container:
        name: main
        image: argoproj/argosay:v2
        command:
          - /argosay
        args:
          - echo
          - '{{inputs.parameters.message}}'
  ttlStrategy:
    secondsAfterCompletion: 300
  podGC:
    strategy: OnPodCompletion

Ensure workflow archives are disabled.

View the workflow details page. Look for the error message before the page loads.

[agilgur5]

For posterity, this was also mentioned in #11671 (reply in thread), #12759 (comment), and maybe others, but a separate issue for this hadn't been filed till now. This has existed since 3.5.0-rc1 and is due to the Archived/Live Workflow UI merge in 3.5 (i.e. #11121).

Also, per Slack, the message only shows up once and quickly disappears, the GIF is showing Ryan refresh a few times to capture the error message.

Initial troubleshooting suggested setting the ARGO_ARTIFACT_SERVER environment variable to false as a potential fix. However, the error persisted on the workflow details page, and archived logs ceased to function after applying this workaround.

Also for reference, that is correct behavior, that suggestion was not correct. Archive Logs and Archived Workflows are two separate features (though often used together), the former of which uses the Artifact Server, the latter of which uses a DB.

[agilgur5]

1. Adjust the frontend code to ensure that archived workflow checks are only performed when necessary, based on the presence of appropriate configuration settings.

Longer-term, I actually think of all of the front-end fallback calls on the Workflow Details page should be rewritten to run in the back-end. That would line up with the intent of #10781.

Also there's technically at least two problems here, one is the retrieval plus error message in the UI, the other is that the server error is a 500 (suggesting it was an unhandled error), as opposed to a 4xx or a different 5xx or something.
404 or 204 could perhaps makes sense. There is no status code for unsupported by the Server which would be most accurate though. Ironically, a 418 almost makes sense for an unsupported request.

[ryancurrah]

Ha funnily enough I do the inverse, I use a coffee press to brew loose leaf tea! Maybe that could be a 218 status code.

Do you think it's worth implementing a workaround or wait for the long term refactor?

My only concern about not resolving this is receiving feedback from users of Argo (At our company) multiple times about the brief error every time they view a workflow detail.

[agilgur5]

about the brief error every time they view a workflow detail.

Yes I agree, and that is why I think it is worth having a shorter term fix. It would also be more correct. Then all of the Details calls could be refactored to run in the back-end later.

The one issue fixing it in the front-end is that it does not currently know of all settings such as Archived Workflows. So the fallback is necessary. But the ordering could be changed and the error could be caught and not shown to the user.

[ryancurrah]

ordering could be changed and the error could be caught and not shown to the user.

Ack I will take peek at this.

[agilgur5]

Longer-term, I actually think of all of the front-end fallback calls on the Workflow Details page should be rewritten to run in the back-end. That would line up with the intent of #10781.

Ok apparently this already exists: #11055 was a precursor to #11121.

So the UI may need some refactoring / simplification as such, as it wouldn't need a fallback then