Troubleshooting

Every message on this page is the real one, copied from the responses the services actually return. If you are reading an error that is not here, it is worth telling us, because an error nobody can look up is a defect in its own right.

terraform init fails with 401 on a module source

HTTP/1.1 401 Unauthorized
www-authenticate: Bearer realm="IaC Bazaar"

{"errors":["This module is free of charge. To download it, create a free
account at https://www.iac-bazaar.com/signup and generate a registry token at
https://www.iac-bazaar.com/account/tokens"]}

This is the expected first response and not a fault. Every module is free, and a token still identifies who is downloading. Two steps, once per machine, in installing through the registry protocol.

If it persists after configuring credentials, check that the credentials block names www.iac-bazaar.com exactly. A host mismatch means the token is never sent, and the response is identical to having no token at all.

terraform init cannot find a version that exists in the catalogue

Error: no available releases match the given constraints

Terraform resolves versions before it authenticates, because the versions endpoint is public. So a version that does not exist fails at selection and never reaches the 401 above. Adding credentials will not fix it, which makes this one easy to misdiagnose.

Ask the registry what it actually has:

curl -s https://www.iac-bazaar.com/api/registry/v1/modules/iac-bazaar/aws-s3-bucket/aws/versions

A module's current version is also on its catalogue page and in /api/v1/modules/{slug}.

A module returns 404 from the registry

{"errors":["not found"]}

The registry returns this for four different situations on purpose, because distinguishing them would tell an unauthenticated caller which modules exist: an unknown slug, the wrong namespace, the wrong target system in the source address, and a module that is not published.

The target system is the usual cause. The address ends in the provider key, so an AWS module is /aws and a Google one is /gcp. The knowledge base entry for each module shows the exact source line.

A module's inputs and outputs are missing from the API response

"contract": { "visible": false, "reason": "sign-in", ... }

Deliberate, and it is the only thing on the public API that is not public. A module's parsed input and output contract ships to a caller sending a registry token. Everything else - verification, checksums, signatures, summaries - needs no account at all.

The marker is present rather than the field being silently absent, so a client can tell “withheld” apart from “this module has no inputs”. See the API reference.

429 rate limited

{"error":"rate limited","retryAfterSeconds":<n>}

Per-IP, and the response tells you exactly how long to wait rather than making you guess. The catalogue endpoints are not throttled; the ones that do real work per call are.

If you are pulling the whole catalogue, ask for it in one request with ?limit= instead of iterating slugs. The list endpoint returns up to 500 modules and carries a shared-cache header.

A module says static-validated, live-test pending

"liveTestStatus": "skipped_quarantine"

The module passed every check that does not need a cloud account, and no sandbox exists for its provider yet, so the live lane has not run. It is not a failure and not a downgrade: it is a smaller claim, stated rather than implied.

Whether that is acceptable is a judgement about your use, and choosing a module by its evidence is about making it deliberately.

A module's security scan says not_applicable

"securityScan": { "status": "not_applicable" }

No policy in the scanner applies to what this module provisions. That is an absence of coverage, not a clean result, and the catalogue never rounds one into the other. A module with no applicable policy is counted separately from one that passed.

Ansible roles report this for Checkov by design: the static lane runs yamllint and ansible-lint on them and no Terraform security scanner, so naming Checkov in their receipt would claim a check that never ran.

A module will not take the provider version I want

Error: locked provider ... does not match configured version constraint

The module pins an upper bound and the version you asked for is above it. That ceiling is deliberate: raising it without re-running the checks would assert a compatibility nobody verified.

Which modules are currently held below a newer release, and by how much, is published on provider freshness. If a ceiling is blocking you, that page is the evidence to point at when asking for it to be raised.

I want to verify a download before running it

Every release publishes a SHA-256 and, where signed, a cosign bundle. The receipt carries both plus the exact commands, so verification does not depend on trusting the page that makes the claim:

curl -s https://www.iac-bazaar.com/api/artifacts/aws-s3-bucket/verification

The same receipt ships inside the tarball as VERIFICATION.json, so what you downloaded carries its own evidence.

Something missing? Tell us. An error a reader cannot look up costs more than the error itself.