Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

3.6.0-rc1 UI: Unable to click Submit button on WorkflowTemplate, ClusterWorkflowTemplate, and CronWorkflow detail. #13453

Closed
3 of 4 tasks
panicboat opened this issue Aug 12, 2024 · 1 comment · Fixed by #13593
Closed
3 of 4 tasks

3.6.0-rc1 UI: Unable to click Submit button on WorkflowTemplate, ClusterWorkflowTemplate, and CronWorkflow detail. #13453

panicboat opened this issue Aug 12, 2024 · 1 comment · Fixed by #13593
Labels
area/ui P2 Important. All bugs with >=3 thumbs up that aren’t P0 or P1, plus: Any other bugs deemed important type/bug
Milestone
v3.6.x patches

Comments

@panicboat
Copy link
Contributor

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?

When I create a new WorkflowTemplate from the UI, the Submit button remains Disabled and cannot be pressed.
The button does not become Enabled even if I perform operations such as Modify->Update.
image

Version(s)

16f0a8e

Paste a minimal 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-tiger
  namespace: argo
  labels:
    example: 'true'
spec:
  workflowMetadata:
    labels:
      example: 'true'
  entrypoint: argosay
  arguments:
    parameters:
      - name: message
        value: hello argo
  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

Logs from the workflow controller

N/A

Logs from in your workflow's wait container

N/A
MasonM added a commit to MasonM/argo-workflows that referenced this issue Sep 12, 2024
@MasonM
fix(ui): Submit button grayed out on details page. Fixes argoproj#13453
77d896c 
The React 18 upgrade in
argoproj#13069 introduced a bug
on the details page where the "Submit" button is disabled immediately on
page load. Specifically, I believe this is happening due to batching
changes that affect the following two `useEffect()` calls, which are
common to all the details pages modified in this PR:
```
    useEffect(() => {
        (async () => {
            try {
                const newEventSource = await services.eventSource.get(name, namespace);
                setEventSource(newEventSource);
                setEdited(false); // set back to false
                setError(null);
            } catch (err) {
                setError(err);
            }
        })();
    }, [name, namespace]);

    useEffect(() => setEdited(true), [eventSource]);
```

The first runs immediately and invokes `setEventSource(newEventSource)`,
which causes the second `useEffect()` call to be fired, since the
`eventSource` dependency has changed. Since both are invoking
`setEdited()`, this is basically a race condition, since the state of
`edited` is going to depend on whether these calls are batched together
are fired separately.

This PR fixes that by removing the second `useEffect()` call, which
eliminates the race condition. Instead, we only call `setEdited(true)`
when the editor is modified.

Signed-off-by: Mason Malone <[email protected]>
MasonM added a commit to MasonM/argo-workflows that referenced this issue Sep 12, 2024
@MasonM
fix(ui): Submit button grayed out on details page. Fixes argoproj#13453
a61d8e3 
The React 18 upgrade in
argoproj#13069 introduced a bug
on the details page where the "Submit" button is disabled immediately on
page load. Specifically, I believe this is happening due to batching
changes that affect the following two `useEffect()` calls, which are
common to all the details pages modified in this PR:
```
    useEffect(() => {
        (async () => {
            try {
                const newEventSource = await services.eventSource.get(name, namespace);
                setEventSource(newEventSource);
                setEdited(false); // set back to false
                setError(null);
            } catch (err) {
                setError(err);
            }
        })();
    }, [name, namespace]);

    useEffect(() => setEdited(true), [eventSource]);
```

The first runs immediately and invokes `setEventSource(newEventSource)`,
which causes the second `useEffect()` call to be fired, since the
`eventSource` dependency has changed. Since both are invoking
`setEdited()`, this is basically a race condition, since the state of
`edited` is going to depend on whether these calls are batched together
are fired separately.

This PR fixes that by removing the second `useEffect()` call, which
eliminates the race condition. Instead, we only call `setEdited(true)`
when the editor is modified.

Signed-off-by: Mason Malone <[email protected]>
MasonM added a commit to MasonM/argo-workflows that referenced this issue Sep 12, 2024
@MasonM
fix(ui): Submit button grayed out on details page. Fixes argoproj#13453
fe7d6be 
The React 18 upgrade in
argoproj#13069 introduced a bug
on the details page where the "Submit" button is disabled immediately on
page load. Specifically, I believe this is happening due to batching
changes that affect the following two `useEffect()` calls, which are
common to all the details pages modified in this PR:
```
    useEffect(() => {
        (async () => {
            try {
                const newEventSource = await services.eventSource.get(name, namespace);
                setEventSource(newEventSource);
                setEdited(false); // set back to false
                setError(null);
            } catch (err) {
                setError(err);
            }
        })();
    }, [name, namespace]);

    useEffect(() => setEdited(true), [eventSource]);
```

The first runs immediately and invokes `setEventSource(newEventSource)`,
which causes the second `useEffect()` call to be fired, since the
`eventSource` dependency has changed. Since both are invoking
`setEdited()`, this is basically a race condition, since the state of
`edited` is going to depend on whether these calls are batched together
are fired separately.

This PR fixes that by removing the second `useEffect()` call, which
eliminates the race condition. Instead, we only call `setEdited(true)`
when the editor is modified.

Signed-off-by: Mason Malone <[email protected]>
@MasonM MasonM mentioned this issue Sep 13, 2024
Merged
@agilgur5 agilgur5 changed the title UI: Unable to click Submit button on WorkflowTemplate, ClusterWorkflowTemplate, and CronWorkflow detail. UI on main: Unable to click Submit button on WorkflowTemplate, ClusterWorkflowTemplate, and CronWorkflow detail. Sep 14, 2024
@agilgur5 agilgur5 added this to the v3.6.0 milestone Sep 14, 2024
@agilgur5 agilgur5 added area/ui P3 Low priority labels Sep 14, 2024
@tico24
Copy link
Member

tico24 commented Sep 18, 2024

Confirmed as an issue in v3.6.0-rc1

@agilgur5 agilgur5 changed the title UI on main: Unable to click Submit button on WorkflowTemplate, ClusterWorkflowTemplate, and CronWorkflow detail. 3.6.0-rc1 UI: Unable to click Submit button on WorkflowTemplate, ClusterWorkflowTemplate, and CronWorkflow detail. Sep 21, 2024
@agilgur5 agilgur5 added P2 Important. All bugs with >=3 thumbs up that aren’t P0 or P1, plus: Any other bugs deemed important and removed P3 Low priority labels Sep 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area/ui P2 Important. All bugs with >=3 thumbs up that aren’t P0 or P1, plus: Any other bugs deemed important type/bug
Projects
None yet
Milestone
v3.6.x patches
3 participants
@panicboat @agilgur5 @tico24