-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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.
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
3.6.0-rc1 UI: Unable to click Submit button on WorkflowTemplate, ClusterWorkflowTemplate, and CronWorkflow detail. #13453
Labels
Milestone
Comments
MasonM
added a commit
to MasonM/argo-workflows
that referenced
this issue
Sep 12, 2024
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 <mmalone@adobe.com>
MasonM
added a commit
to MasonM/argo-workflows
that referenced
this issue
Sep 12, 2024
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 <mmalone@adobe.com>
MasonM
added a commit
to MasonM/argo-workflows
that referenced
this issue
Sep 12, 2024
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 <mmalone@adobe.com>
agilgur5
changed the title
UI: Unable to click Submit button on WorkflowTemplate, ClusterWorkflowTemplate, and CronWorkflow detail.
UI on Sep 14, 2024
main
: Unable to click Submit button on WorkflowTemplate, ClusterWorkflowTemplate, and CronWorkflow detail.
Confirmed as an issue in v3.6.0-rc1 |
agilgur5
changed the title
UI on
3.6.0-rc1 UI: Unable to click Submit button on WorkflowTemplate, ClusterWorkflowTemplate, and CronWorkflow detail.
Sep 21, 2024
main
: Unable to click Submit button on WorkflowTemplate, ClusterWorkflowTemplate, and CronWorkflow detail.
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
Pre-requisites
: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.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.
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.
Logs from the workflow controller
Logs from in your workflow's wait container
The text was updated successfully, but these errors were encountered: