Unclear error when deploying to improperly-tagged container app in non-revision mode

[JeffreyCA]

azd used to return a useful, detailed error when deploying to an ACA resource that was improperly tagged:

ERROR: getting target resource: resource not found: unable to find a resource tagged with 'azd-service-name: CalculatorAgentLG'. Ensure the service resource is correctly tagged in your infrastructure configuration, and rerun provision

Now the error returned in this scenario is:

ERROR: failed deploying service 'CalculatorAgentLG': updating container app service: getting container app: getting container app: parameter containerAppName cannot be empty

I'm suspecting this might be a result of the changes in #5694 to swallow ResourceNotFound errors for Container App resources:

azure-dev/cli/azd/pkg/project/resource_manager.go

Lines 234 to 254 in 4170334

	func (rm *resourceManager) resolveServiceResource(
	ctx context.Context,
	subscriptionId string,
	resourceGroupName string,
	serviceConfig *ServiceConfig,
	rerunCommand string,
	) (*azapi.ResourceExtended, error) {
	azureResource, err := rm.GetServiceResource(ctx, subscriptionId, resourceGroupName, serviceConfig, rerunCommand)
	// If the service target supports delayed provisioning, the resource isn't expected to be found yet.
	// Return the empty resource
	var resourceNotFoundError *azureutil.ResourceNotFoundError
	if err != nil &&
	errors.As(err, &resourceNotFoundError) &&
	ServiceTargetKind(serviceConfig.Host).SupportsDelayedProvisioning() {
	return &azapi.ResourceExtended{}, nil
	}
	if err != nil {
	return nil, err
	}

[weikanglim]

Mentioning this in case this is useful for anyone:

When I implemented the initial solution, I attempted to "do the right thing" here by explicitly checking for the resource existence in the default path as a way to provide the same error message:

azure-dev/cli/azd/pkg/project/service_target_containerapp.go

Lines 277 to 285 in 4170334

	} else {
	if resourceName == "" {
	// Fetch the target resource explicitly
	res, err := at.resourceManager.GetTargetResource(ctx, at.env.GetSubscriptionId(), serviceConfig)
	if err != nil {
	return nil, fmt.Errorf("fetching target resource: %w", err)
	}
	targetResource = res

Unknowingly, there was a change to the behavior of GetTargetResource.

The current implementation doesn't offer a direct API to find the target resource cleanly, but rather delegates back to resolveServiceResource (an intended lifecycle business logic) which was unexpected for me. This was changed in a bigger refactor awhile back.

[weikanglim]

With all that being said, a better route for us moving forward would be to leverage the custom target resource resolution and deprecate the SupportsDelayedProvisioning functionality to better localize the implementation.