Add AlreadyExistsResult as a possible return value for CreateAccountResponse.

[ggreer]

Summary by CodeRabbit

• New Features
  • Account creation now surfaces explicit "already exists" and "in progress" result types so responses are clearer.
• Bug Fixes
  • Validation expanded for these new result types to consistently validate embedded resources and report multiple violations.
• Style / Tests
  • Validation errors now include richer, structured details to make issues easier to inspect and diagnose.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

Added two new nested result messages (AlreadyExistsResult, InProgressResult) to CreateAccountResponse, generated corresponding Go validation scaffolding for both oneof branches (including composite and detailed validation error types), and extended builder logic to handle the new result variants.

Changes

Cohort / File(s)	Summary
Protobuf Schema proto/c1/connector/v2/resource.proto	Added nested messages AlreadyExistsResult and InProgressResult inside CreateAccountResponse and extended the result oneof with already_exists (field 102) and in_progress (field 103). Both include Resource and is_create_account_result fields.
Generated Go Validation pb/c1/connector/v2/resource.pb.validate.go	Added validation for CreateAccountResponse_AlreadyExistsResult and CreateAccountResponse_InProgressResult: public Validate() / ValidateAll() methods, internal validate(all bool) implementations, composite multi-error types (*MultiError), detailed validation error types (*ValidationError) with accessors (Field, Reason, Cause, Key, ErrorName) and formatted Error() methods, interface assertions and exported error vars. Duplicate insertion blocks added for parity with other oneof branches.
Builder Logic pkg/connectorbuilder/accounts.go	Extended CreateAccount result handling to recognize and map CreateAccountResponse_AlreadyExistsResult and CreateAccountResponse_InProgressResult to the response builder via SetAlreadyExists and SetInProgress.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

• Inspect proto/c1/connector/v2/resource.proto for correct field numbering and message structure.
• Review pb/c1/connector/v2/resource.pb.validate.go for correct nil/typed-nil handling, correctness of validation branching, error message formatting, and intentional duplicate insertion points.
• Verify pkg/connectorbuilder/accounts.go mapping for the new oneof cases and any related tests or usage sites.

Suggested reviewers

• morgabra
• johnallers
• loganintech

Poem

I hop through lines of proto and code,
Two new results find their road.
Validators stitched, builders aligned,
A tiny rabbit — change defined. 🐇✨

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarizes the main change—adding AlreadyExistsResult as a possible return value for CreateAccountResponse—which is the primary objective of this PR.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch ggreer/create-account-already-exists

---

📜 Recent review details

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 7319226 and b71b345.

⛔ Files ignored due to path filters (2)

• pb/c1/connector/v2/resource.pb.go is excluded by !**/*.pb.go
• pb/c1/connector/v2/resource_protoopaque.pb.go is excluded by !**/*.pb.go

📒 Files selected for processing (3)

• pb/c1/connector/v2/resource.pb.validate.go (2 hunks)
• pkg/connectorbuilder/accounts.go (1 hunks)
• proto/c1/connector/v2/resource.proto (1 hunks)

🚧 Files skipped from review as they are similar to previous changes (1)

• pkg/connectorbuilder/accounts.go

🧰 Additional context used

🧬 Code graph analysis (1)

pb/c1/connector/v2/resource.pb.validate.go (1)

pb/c1/connector/v2/resource.pb.go (8)

• CreateAccountResponse_AlreadyExists (2267-2269)
• CreateAccountResponse_AlreadyExists (2279-2279)
• CreateAccountResponse_InProgress (2271-2273)
• CreateAccountResponse_InProgress (2281-2281)
• CreateAccountResponse_AlreadyExistsResult (4214-4220)
• CreateAccountResponse_AlreadyExistsResult (4233-4233)
• CreateAccountResponse_InProgressResult (4296-4302)
• CreateAccountResponse_InProgressResult (4315-4315)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: go-test (1.25.2, windows-latest)

🔇 Additional comments (4)

proto/c1/connector/v2/resource.proto (1)

228-240: LGTM! Well-structured addition of new result types.

The new AlreadyExistsResult and InProgressResult messages follow the existing pattern established by SuccessResult and ActionRequiredResult. Field numbers 102 and 103 are appropriately sequential, and the structure is consistent across all result types.

The comment on Line 233 appropriately documents that the Resource field is optional for InProgressResult, which makes sense for asynchronous account creation scenarios where the resource may not be immediately available.

pb/c1/connector/v2/resource.pb.validate.go (3)

3116-3197: Generated validation code follows established patterns.

The validation cases for CreateAccountResponse_AlreadyExists and CreateAccountResponse_InProgress correctly mirror the existing validation logic for Success and ActionRequired result types, including:

• Typed-nil checks for the oneof value
• Embedded message validation with support for both single-error and all-errors modes
• Consistent error handling and reporting

---

6372-6507: Validation implementation for AlreadyExistsResult is correct.

The generated validation code for CreateAccountResponse_AlreadyExistsResult follows the same pattern as existing result types (e.g., SuccessResult), including:

• Public Validate() and ValidateAll() entry points
• Internal validate(all bool) with proper Resource validation
• Comprehensive error types with all required accessors
• Proper interface assertions

---

6509-6644: Validation implementation for InProgressResult is correct.

The generated validation code for CreateAccountResponse_InProgressResult properly implements:

• Standard validation entry points and internal validation logic
• Resource field validation consistent with other result types
• Complete error type definitions with required methods and interface conformance

The validation handles the optional nature of the Resource field appropriately through proto3's default semantics (nil-safe access via GetResource()).

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[kans]

What about the deletion side?

[ggreer]

For deletion we could add an annotation similar to GrantAlreadyRevoked, but returning nil seems fine for now.