I noticed that the connection wasn’t returning all the parameters in the first message,

This is a good observation. The first message is incorrect because it assumes 0 inputs. The first message the webui sends is the inputs, and the next response is the true initial form.

0. Websocket is opened
1. <- Initial form state sent to webui (incorrect because assumes 0 inputs)
2. WebUI sends over actual initial values ->
3. <- New form state (the actual initial)

So I wonder if we need a way to open the websocket with some initial input values? Or ignore the first state back?

@jaaydenh I think you would have the most insight here.

@Emyrk could I ask you to QA it locally and see if it works as expected? I don’t want to spend more time thinking about it without being sure this actually fixes the problem. I tested it myself, but a double check never hurts. 🙏

The form is having errors even when switching another value too.

The websocket traffic is strange to me.

That first message sent from the client has all the parameter values set to the initial default values. But it should not be sending any inputs yet, as the user took no action yet. And default values should be omitted.

So the second message from the client only has the parameter that was changed. The others revert back to their default of unset.

@BrunoQuaresma it does fix it. The error message you see in this video happens on dogfood too when it also resets the Volume Size.

@steve-Coder-Ent about the error message, I think it happens because you are selecting the already selected option, which unselects it and sets the field value to null.

That first message sent from the client has all the parameter values set to the initial default values. But it should not be sending any inputs yet, as the user took no action yet. And default values should be omitted.

So the following code should not be necessary, correct?

// On page load, sends initial workspace build parameters to the websocket.
// This ensures the backend has the form's complete initial state,
// vital for rendering dynamic UI elements dependent on initial parameter values.
const sendInitialParameters = useEffectEvent(() => {
	if (initialParamsSentRef.current) return;
	if (autofillParameters.length === 0) return;

	const initialParamsToSend: Record<string, string> = {};
	for (const param of autofillParameters) {
		if (param.name && param.value) {
			initialParamsToSend[param.name] = param.value;
		}
	}
	if (Object.keys(initialParamsToSend).length === 0) return;

	sendMessage(initialParamsToSend);
	initialParamsSentRef.current = true;
});

Which also makes me wonder, if the BE already has all the necessary information, why can’t the first websocket message contain the correct values?

This does fix the issue atleast temporarily but the root cause is that the frontend is using formik's touched fields state to keep track of which form fields should always be sent to the server on every request. If a field, that has a legitimate value that we want to maintain on the frontend, is not sent in a request, then the backend will always return that field with its default value which is the incorrect behavior in this case.

I am still investigating what the proper fix should be.

@jaayden is this something you’d like to assign to yourself, or should I take it over? I just want to make sure we don’t duplicate efforts.

I’d be more than happy to help and dive deeper into this, but if you think you can get it done faster, I’m totally fine with that. Please let me know what you think.