golang SDK eventgrid EventSubscriptionArgs Destination examples do not work

[tjholm]

Hello!

• Vote on this issue by adding a 👍 reaction
• To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already)

Issue details

Trying to create a new eventgrid EventSubscription using golang and azure-native v1.60.0 following Webhook example at: https://www.pulumi.com/registry/packages/azure-native/api-docs/eventgrid/eventsubscription/

Steps to reproduce

1. Attempt to create new eventgrid EventSubscription in golang using the webhook example https://www.pulumi.com/registry/packages/azure-native/api-docs/eventgrid/eventsubscription/ using azure-native v1.60.0.

Expected: Destination field accepts eventgrid.WebHookEventSubscriptionDestination Actual: typing is not correct (program cannot be compiled, eventgrid.WebHookEventSubscriptionDestination does not implement pulumi.Input)

[viveklak]

Thanks for the above. I believe using WebHookEventSubscriptionDestinationArgs should help getting unblocked here.

[tjholm]

@viveklak thanks for your reply. I'm probably missing something but I don't think such a type exists for golang, at least not in v1.60.0 https://pkg.go.dev/github.com/pulumi/pulumi-azure-native/[email protected]/go/azure/eventgrid

[Zaid-Ajaj]

I believe this is resolved by https://github.com/pulumi/pulumi/pull/14679 which now should allow azure-native to emit the WebHookEventSubscriptionDestinationArgs type on the next release cycle

[mikhailshilkov]

@Zaid-Ajaj The provider is now on pulumi 3.109.0 but the docs issue is still present. Could you please take another look?

[Zaid-Ajaj]

Looking into this again, it remains a bug unfortunately. With https://github.com/pulumi/pulumi/pull/14679 merged, this was supposed to be fixed. In fact, generating the azure-native SDK locally does correctly generate the Args version of WebHookEventSubscriptionDestination:

Repro with:

pulumi version # 3.116.1

# get schema
pulumi package get-schema azure-native > schema.json

# generate sdk locally
pulumi package gen-sdk --language go --out sdk schema.json

Will give you these types under ./sdk/go/eventgrid/pulumiTypes.go

See generated types:

// Information about the webhook destination for an event subscription.
type WebHookEventSubscriptionDestination struct {
	// The Azure Active Directory Application ID or URI to get the access token that will be included as the bearer token in delivery requests.
	AzureActiveDirectoryApplicationIdOrUri *string `pulumi:"azureActiveDirectoryApplicationIdOrUri"`
	// The Azure Active Directory Tenant ID to get the access token that will be included as the bearer token in delivery requests.
	AzureActiveDirectoryTenantId *string `pulumi:"azureActiveDirectoryTenantId"`
	// Delivery attribute details.
	DeliveryAttributeMappings []interface{} `pulumi:"deliveryAttributeMappings"`
	// Type of the endpoint for the event subscription destination.
	// Expected value is 'WebHook'.
	EndpointType string `pulumi:"endpointType"`
	// The URL that represents the endpoint of the destination of an event subscription.
	EndpointUrl *string `pulumi:"endpointUrl"`
	// Maximum number of events per batch.
	MaxEventsPerBatch *int `pulumi:"maxEventsPerBatch"`
	// Preferred batch size in Kilobytes.
	PreferredBatchSizeInKilobytes *int `pulumi:"preferredBatchSizeInKilobytes"`
}

// Defaults sets the appropriate defaults for WebHookEventSubscriptionDestination
func (val *WebHookEventSubscriptionDestination) Defaults() *WebHookEventSubscriptionDestination {
	if val == nil {
		return nil
	}
	tmp := *val
	if tmp.MaxEventsPerBatch == nil {
		maxEventsPerBatch_ := 1
		tmp.MaxEventsPerBatch = &maxEventsPerBatch_
	}
	if tmp.PreferredBatchSizeInKilobytes == nil {
		preferredBatchSizeInKilobytes_ := 64
		tmp.PreferredBatchSizeInKilobytes = &preferredBatchSizeInKilobytes_
	}
	return &tmp
}

// WebHookEventSubscriptionDestinationInput is an input type that accepts WebHookEventSubscriptionDestinationArgs and WebHookEventSubscriptionDestinationOutput values.
// You can construct a concrete instance of `WebHookEventSubscriptionDestinationInput` via:
//
//	WebHookEventSubscriptionDestinationArgs{...}
type WebHookEventSubscriptionDestinationInput interface {
	pulumi.Input

	ToWebHookEventSubscriptionDestinationOutput() WebHookEventSubscriptionDestinationOutput
	ToWebHookEventSubscriptionDestinationOutputWithContext(context.Context) WebHookEventSubscriptionDestinationOutput
}

// Information about the webhook destination for an event subscription.
type WebHookEventSubscriptionDestinationArgs struct {
	// The Azure Active Directory Application ID or URI to get the access token that will be included as the bearer token in delivery requests.
	AzureActiveDirectoryApplicationIdOrUri pulumi.StringPtrInput `pulumi:"azureActiveDirectoryApplicationIdOrUri"`
	// The Azure Active Directory Tenant ID to get the access token that will be included as the bearer token in delivery requests.
	AzureActiveDirectoryTenantId pulumi.StringPtrInput `pulumi:"azureActiveDirectoryTenantId"`
	// Delivery attribute details.
	DeliveryAttributeMappings pulumi.ArrayInput `pulumi:"deliveryAttributeMappings"`
	// Type of the endpoint for the event subscription destination.
	// Expected value is 'WebHook'.
	EndpointType pulumi.StringInput `pulumi:"endpointType"`
	// The URL that represents the endpoint of the destination of an event subscription.
	EndpointUrl pulumi.StringPtrInput `pulumi:"endpointUrl"`
	// Maximum number of events per batch.
	MaxEventsPerBatch pulumi.IntPtrInput `pulumi:"maxEventsPerBatch"`
	// Preferred batch size in Kilobytes.
	PreferredBatchSizeInKilobytes pulumi.IntPtrInput `pulumi:"preferredBatchSizeInKilobytes"`
}

@danielrbradley @thomas11 do we by any chance split the schema into sub-schemas when generating azure-native modules? In that case, SDK-gen might not infer that the type used from a union as input (depending on how the subschemas are split) you might require adding generateExtraInputType: true into your $.language.go options for each sub schema to ensure that these types are generated.

The option generateExtraInputType should probably be set to true anyways since there are no plain types in azure-native AFAIK

[thomas11]

Thank you @Zaid-Ajaj. I'm not sure I understand this correctly:

do we by any chance split the schema into sub-schemas when generating azure-native modules?

here we load the whole schema and use it in an hcl2.Loader to generate the examples.

Why is generateExtraInputType not the default? What's the potential downside of turning it on?

[mikhailshilkov]

Why is generateExtraInputType not the default? What's the potential downside of turning it on?

My guess is that the SDK size may be a concern.

[Zaid-Ajaj]

here we load the whole schema and use it in an hcl2.Loader to generate the examples.

The problem is not only the example generation, it is that the SDK itself is missing some output-versioned types

Why is generateExtraInputType not the default? What's the potential downside of turning it on?

generateExtraInputTypes is an optimization such that if a type is only used in properties which are marked plain, then the output-versioned variant of that type does not need to be generated. Like @mikhailshilkov said, this is to decrease size of the generated sdk. However, in case of azure-native, it is not required (as shown by my repro above, the output-versioned variants are generated without generateExtraInputTypes being set) but something is going wrong with smaller modules of azure-native if you are generating sub schemas and genning sdks from each of these schemas