Issue details
patches/0001-expose-providers.patch passes the literal string "pulumi" where upstream expects the provider's semver:
func PFProvider() provider.Provider {
return internal.NewProvider("pulumi")()
}
Upstream stores that argument as CloudflareProvider.version and uses it in three places (internal/provider.go):
- the leading
User-Agent token — terraform-provider-cloudflare/pulumi
- the
x-stainless-package-version header — pulumi
resp.Version in Metadata() (Terraform-internal; the bridge never surfaces it)
So today every Cloudflare API request we make carries:
User-Agent: terraform-provider-cloudflare/pulumi terraform-plugin-framework/1.19.0 pulumi/<version>
x-stainless-package-version: pulumi
The trailing pulumi/<version> is deliberate and correct — that's the operator suffix added in #179. The leading terraform-provider-cloudflare/pulumi is not: it claims a provider version of pulumi, which is not a version, and it means Cloudflare's own Stainless telemetry can't tell which upstream release we're bridging.
Why this wasn't fixed alongside #179
Every obvious replacement has a downside:
- Pass
version.Version (the Pulumi provider version) → terraform-provider-cloudflare/6.x.y, which claims an upstream release that doesn't exist. Upstream is on v5. Actively misleading.
- Pass
"pulumi/" + version.Version → terraform-provider-cloudflare/pulumi/6.x.y, which breaks the name/version token grammar and pollutes x-stainless-package-version the same way.
- Hardcode the real upstream version (e.g.
"5.23.0") → correct and truthful, but upgrade-provider won't touch the patch, so it silently rots the moment we bump the submodule.
Proposed fix
Hardcode the upstream version in the shim patch, and add a guard test that compares it against the checked-out submodule tag (git -C upstream describe --tags) so a stale value fails CI on the next upgrade instead of shipping quietly.
Alternatively, thread the version through from resources.go by changing PFProvider() to take a version string argument, sourcing it from the same place the upgrade automation already updates.
Context
Issue details
patches/0001-expose-providers.patchpasses the literal string"pulumi"where upstream expects the provider's semver:Upstream stores that argument as
CloudflareProvider.versionand uses it in three places (internal/provider.go):User-Agenttoken —terraform-provider-cloudflare/pulumix-stainless-package-versionheader —pulumiresp.VersioninMetadata()(Terraform-internal; the bridge never surfaces it)So today every Cloudflare API request we make carries:
The trailing
pulumi/<version>is deliberate and correct — that's the operator suffix added in #179. The leadingterraform-provider-cloudflare/pulumiis not: it claims a provider version ofpulumi, which is not a version, and it means Cloudflare's own Stainless telemetry can't tell which upstream release we're bridging.Why this wasn't fixed alongside #179
Every obvious replacement has a downside:
version.Version(the Pulumi provider version) →terraform-provider-cloudflare/6.x.y, which claims an upstream release that doesn't exist. Upstream is on v5. Actively misleading."pulumi/" + version.Version→terraform-provider-cloudflare/pulumi/6.x.y, which breaks thename/versiontoken grammar and pollutesx-stainless-package-versionthe same way."5.23.0") → correct and truthful, butupgrade-providerwon't touch the patch, so it silently rots the moment we bump the submodule.Proposed fix
Hardcode the upstream version in the shim patch, and add a guard test that compares it against the checked-out submodule tag (
git -C upstream describe --tags) so a stale value fails CI on the next upgrade instead of shipping quietly.Alternatively, thread the version through from
resources.goby changingPFProvider()to take aversion stringargument, sourcing it from the same place the upgrade automation already updates.Context
0002works around: user_agent_operator_suffix is sent double-quoted in the User-Agent header cloudflare/terraform-provider-cloudflare#7323