Why does ADU call Apply on Install step?

[AndreRicardo-Zoetis]

Why does ADU in the ADUCITF_WorkflowStep_Install call both Install and Apply in the step handler?

https://github.com/Azure/iot-hub-device-update/blob/release/1.2.0/src/extensions/update_manifest_handlers/steps_handler/src/steps_handler.cpp#L1014

In our workflow this means that Apply is called twice.

Specially because Install auto transitions to Apply.
https://github.com/Azure/iot-hub-device-update/blob/release/1.2.0/src/adu_workflow/src/agent_workflow.c#L282

It is also confusing because I cannot see this rational in the documentation under https://github.com/Azure/iot-hub-device-update/blob/1.2.0/docs/agent-reference/goal-state-support.md#state-machine-diagram

[OscarLeeMSFT]

Hello, we will look into your question and get back to you in the next few days.

[OscarLeeMSFT]

With updates that involve steps, it is possible for some of these steps to depend on the successful completion of others. The implementation could have the Install include both the logic for Install and Apply before moving to the next step in a sequential manner. More details can also be found here.

That being said, this Step Handler logic could be customized to meet the specific requirements that your scenarios may have, to reflect a breadth-first approach, a depth-first approach or something in between for the actions.

Hope this helps, and have a good day!

[AndreRicardo-Zoetis]

Hi @OscarLeeMSFT thank you for the response. I've gone through the documentation you linked and seems based on the sequence diagrams shown that the steps are ran in order, first Install, then Apply. The loops documented are on Install, then another loop on Apply. No mention about BFS, DFS approaches anywhere that I could see, not a single mention of "breath" in the repo, also nothing mentioning depth-first, really confusing see this first mentioned here...

No mention of this customization on https://github.com/Azure/iot-hub-device-update/blob/develop/docs/agent-reference/how-to-implement-custom-update-handler.md either. Everything points to being a series of steps ran in order according to the state diagram used by ADU https://github.com/Azure/iot-hub-device-update/blob/develop/docs/agent-reference/goal-state-support.md#state-machine-diagram.

The documentation for the custom step handler states "The apply task usually includes one or more additional steps after an 'install' task has completed." The Install function mentions nothing about about Apply also being called.

Only the code mentions that "Apply" is no-op, with I really don't understand because in reality we are seeing reboot being called twice, once for Install another for Apply.

iot-hub-device-update/src/extensions/update_manifest_handlers/steps_handler/src/steps_handler.cpp

Lines 1147 to 1170 in 3392254

	/**
	* @brief This function is no-op because 'Apply' action for every step
	* were invoked inside the 'StepsHandler::Install' function.
	* @return ADUC_Result The result (ADUC_Result_Apply_Success)
	*/
	static ADUC_Result StepsHandler_Apply(const tagADUC_WorkflowData* workflowData)
	{
	ADUC_Result result;
	if (workflow_is_cancel_requested(workflowData->WorkflowHandle))
	{
	result.ResultCode = ADUC_Result_Failure_Cancelled;
	result.ExtendedResultCode = 0;
	return result;
	}
	// Since the child-step's Install and Apply tasks have already been processed in 'StepsHandler_Install' function,
	// the Apply task for this workflow is no-op.
	Log_Debug("Apply task at level %d is no-op.", workflow_get_level(workflowData->WorkflowHandle));
	result.ResultCode = ADUC_Result_Apply_Success;
	result.ExtendedResultCode = 0;
	return result;
	}

[jw-msft]

Thanks @AndreRicardo-Zoetis for the feedback. You're right that the documentation needs updating to reflect the current implementation.

The architecture evolved from a simple state machine to include a steps handler for processing metadata with multiple content handlers and MCU/proxy updates. The Install state now delegates to the steps handler, which processes steps in a depth-first manner.

Some reconciliation work between the state machine and steps handler paradigms was deprioritized, leading to patterns like the StepsHandler_Apply no-op to avoid duplicate operations.

We'll prioritize documentation updates and targeted fixes in upcoming work. The reboot behavior is controlled by content handler return codes.

Regarding Apply being called twice - this shouldn't happen despite the steps handler doing Install+Apply. Could you share:

1. Your metadata structure
2. Relevant log excerpts showing the duplicate Apply calls

This will help us identify the root cause. Thanks!

[HenrikAndreasen-Zoetis]

I looked a little deeper into this matter and I can see that the "no-op blocking" of our apply code does indeed work but the way it is blocked in StepsHandler_Apply means that the agent_workflow sees the Apply as a success and because the workflowData still contains the request for an immediate reboot a second reboot is ordered from ADUC_Workflow_MethodCall_Apply_Complete.

In my opinion, if you want to change the way the workflow flows, it should be changed in the workflow agent, not deep in a secondary mechanism.

Also, I do not see any reason for this change. If I want tings that happen in the apply step to occur in the install step, I can simply move that code into the install step. There is no need what so ever to mash two steps into one. With this change you have barred us from selecting the breadth-first style strategy.