provider-generator: generated docs links use the fetching CLI's registry hostname, producing 404s under OpenTofu

[jsteinich]

Summary

Generated bindings embed a documentation link built from the fetching CLI's registry hostname. Under OpenTofu that produces 404 links, and it makes generated output differ by which CLI ran cdktn get — so provider-generator and integration snapshots are not comparable across a Terraform leg and an OpenTofu leg. This is a blocker for the matrix work in #337, and a user-facing bug today for anyone running cdktn get with TERRAFORM_BINARY_NAME=tofu.

Detail

ResourceModel.linkToDocs derives the docs URL from the fully-qualified provider name:

// packages/@cdktn/provider-generator/src/get/generator/models/resource-model.ts:112
const { hostname, namespace, name } = parseFQPN(this.fqpn);
const version = this.providerVersion || "latest";
const base = `https://${hostname}/providers/${namespace}/${name}/${version}/docs`;

The FQPN key comes straight from <cli> providers schema -json, and the two CLIs key the same provider differently. Verified with the versions being added to the CI image (Terraform 1.16.1, OpenTofu 1.12.6, hashicorp/random 3.7.2 + hashicorp/time 0.13.1):

tofu 1.12.6        registry.opentofu.org/hashicorp/random   ephemeral=1
                   registry.opentofu.org/hashicorp/time     functions=3
terraform 1.16.1   registry.terraform.io/hashicorp/random   ephemeral=1
                   registry.terraform.io/hashicorp/time     functions=3

The schema contents agree; only the hostname in the key differs. But that hostname is what the docs link is built from:

URL	Status
https://registry.terraform.io/providers/hashicorp/random/3.7.2/docs	200
https://registry.opentofu.org/providers/hashicorp/random/3.7.2/docs	404
https://search.opentofu.org/provider/hashicorp/random/v3.7.2/	200

OpenTofu's provider docs are not merely on a different host — the path shape differs too (/provider/ singular, v-prefixed version). So the registry hostname cannot be substituted directly into the existing template.

What is already handled

Scoping this narrowly, because the rest of the OpenTofu hostname path is already correct:

• Schema lookup tolerates both hostnames — isMatching in packages/@cdktn/provider-generator/src/get/generator/provider-generator.ts:60-93 deliberately does not assume a default hostname for shorthand sources, with a comment naming exactly this divergence.
• The schema cache is already CLI-aware — resolveCacheKeySuffix in packages/@cdktn/provider-schema/src/read.ts:37-52 puts <cli-name>-<major>.<minor> into the cache key, so a tofu-fetched schema is not served as a terraform-fetched one.

The docs link is the remaining place where the fetching CLI leaks into generated output.

Suggested direction

Map registry hostname → docs-URL builder rather than assuming the registry host also serves docs at /providers/<ns>/<name>/<version>/docs. registry.opentofu.org would map to a search.opentofu.org/provider/<ns>/<name>/v<version>/ builder; unknown hostnames (private registries) keep the current behaviour.

Worth deciding explicitly whether the emitted link should follow the fetching CLI at all, or whether generated bindings should carry a stable canonical link regardless of which CLI produced them — the latter would also make snapshots identical across matrix legs, which is what #337 needs.

Relations

• CI: thin-slice runtime coverage for newer-protocol features on current stable Terraform AND OpenTofu #337 — OpenTofu matrix coverage, which this blocks
• dependency-manager: migrate to opentofu registry #208 — dependency-manager still resolves versions against registry.terraform.io regardless of CLI
• test(tofu): terraform-cloud test feeds the matrix version into an HCP Terraform workspace, blocking an OpenTofu matrix leg #392 — the other untracked OpenTofu matrix blocker