* Repair corrupted GroupMember state so deploys stop failing (#133) Every Deploy to Production run since 2026-06-30 aborts about a minute in with "googleapi: Error 409: Member already exists" and merged changes (e.g. #134, #137) never apply. Two external-email GroupMember records in the maintainers group are recorded in state with an empty member ID ("groups/04f1mdlm38smb30/members/"), so each pulumi up plans a create-before-delete replace whose create conflicts with the live membership and fails the whole update. Five other records corrupted at the same time were already healed by the 2026-07-02 deploy run. Add a one-time TEMP block to the deploy workflow (same precedent as the auth-maintainers repair and the experimental-ext-tasks state delete): drop the two broken records, then re-import each membership by member email so the provider records the numeric member ID. All commands are || true-guarded, and the block must be removed after one successful deploy. Fixes #133 Co-authored-by: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NazA3QKftRn72tdPG5vrpb * Widen state repair to all seven corrupted GroupMember records (#133) * Replace per-URN state deletes with export surgery; verify healing post-deploy (#133) The committed repair used 'pulumi state delete <urn>' per record, but the failed create-before-delete replaces left duplicate same-URN entries (a live record plus a pending-delete leftover) for some of the seven corrupted GroupMember records. 'pulumi state delete' fails on an ambiguous URN, and the '|| true' guard hid that failure, making the repair a silent no-op. - Replace the per-URN deletes with state surgery: export the stack, drop every entry (including pending-delete duplicates) whose URN is one of the seven with jq, and re-import. Unguarded, so a surgery failure is loud; skips the import when nothing matches (idempotent). - Keep the seven imports-by-email ('|| true' so a not-currently-live membership falls back to a create instead of blocking the deploy). - Add a post-deploy verification step that fails if any GroupMember record still has an empty member ID or a duplicate URN. The pinned provider (SamuZad/googleworkspace 0.11.1) writes an empty member ID even on successful creates (fixed upstream in 0.11.2), so a green 'make up' alone does not prove healing; the TEMP block must only be removed after this verification step passes. - Correct the root-cause comment: Google-side membership removals -> refresh dropped the records -> re-create -> provider create bug wrote empty IDs. * Bump googleworkspace provider 0.11.1 -> 0.11.2 (#133) 0.11.2 carries upstream commit "handle edge case with group memberships" (SamuZad/terraform-provider-googleworkspace, 2026-03-12), which fixes the create-path bug that stores an empty member ID for external-email group members — the bug that corrupted the seven records repaired by the TEMP block in deploy.yml and that would re-corrupt any record restored via the fallback create path. CI regenerates the SDK from this pin via 'pulumi install' and typechecks against it. --------- Co-authored-by: Claude <noreply@anthropic.com>

Uh oh!

Deploy to Production Failed #133

Description

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions