A Google-Cloud-compatible surface, grown on a machine rented from lola
b542edf9a7
A real consumer hit a real failure. The official Terraform google provider (v6, storage_custom_endpoint pointed at this cloud) ran terraform apply for a google_storage_bucket and failed with: "json: invalid use of ,string struct tag, trying to unmarshal \"sovereign-1\" into uint64". Cause: our bucket resource returns the project ID where Google returns projectNumber. In real GCS a project has TWO identifiers - projectId, a human string like sovereign-1, and projectNumber, an unsigned 64-bit integer serialised in JSON as a decimal string like \"123456789012\". The storage#bucket resource carries projectNumber, never the projectId. Fix this properly: give the project model a stable numeric projectNumber assigned when a project is first seen and persisted so it never changes, and return it in every storage#bucket response. Then audit every other field we emit against the real GCS JSON API for the same class of mistake - wrong type, wrong name, or a value that will not survive the provider typed client. Also check the bucket etag: we currently emit \"CAE=1\" which looks like a concatenation bug, since real GCS bucket etags look like \"CAE=\". Add regression tests that assert projectNumber is numeric-as-string and that no field carries a project ID where a number is required. Build with: mvn -f lambda/pom.xml -Dsola.container=true clean package. Build and all tests MUST pass or your work is reverted. Do not weaken or delete existing tests. |
||
|---|---|---|
| lambda | ||
| scripts | ||
| .gitignore | ||
| AGENTS.md | ||
| MISSION.md | ||