8000 feat: connectors sdks test e2e by paul-nicolas · Pull Request #401 · formancehq/payments · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

feat: connectors sdks test e2e #401

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 7 commits into from
Apr 8, 2025
Merged

feat: connectors sdks test e2e #401

merged 7 commits into from
Apr 8, 2025

Conversation

paul-nicolas
Copy link
Contributor
@paul-nicolas paul-nicolas commented Apr 7, 2025 •
edited
Loading

Fixes PMNT-89

@coderabbitai coderabbitai
Copy link
Contributor
coderabbitai bot commented Apr 7, 2025 •
edited
Loading

Walkthrough

This pull request implements extensive refactoring across documentation, internal APIs, models, and tests. Major updates include a restructuring of JSON schema definitions for connector configurations, a migration from the old ConnectorEnum type to a more general Connector type, and a new function to convert payment schemes. Method signatures, data structures, and test cases have been updated accordingly, with several files removed or reformatted to enhance clarity and type safety.

Changes

File Group Change Summary
docs/api/README.md JSON schema definitions for connector configurations restructured with new properties and default values.
internal/api/v2/handler_payments_create.go
internal/api/v2/utils.go		 Payment creation flow updated: added toV3PaymentScheme conversion and explicit status assignment.
internal/models/payment_scheme.go Updated constant declaration to explicitly use the PaymentScheme type.
pkg/client/docs/models/components/* Connector documentation overhauled: new connector.md added; deprecated connectorenum.md and related files removed; field type and table formatting changes.
pkg/client/docs/models/operations/* Operation documentation updated: type references for Connector now point to the new Connector type instead of ConnectorEnum.
pkg/client/docs/sdks/v1/README.md
pkg/client/models/components/bankaccountrequest.go		 SDK method signatures updated and BankAccountRequest field changed from non-pointer to pointer for ConnectorID.
pkg/client/models/components/connector.go New file introducing the Connector type, constants, and associated methods (ToPointer, UnmarshalJSON).
pkg/client/models/operations/* Numerous request structs and methods updated: switched fields and return types from ConnectorEnum to Connector.
pkg/client/v1.go Updated method signatures in the V1 client to use Connector instead of ConnectorEnum for connector parameters.
pkg/testserver/api.go Entire file removed, eliminating legacy test server API functions.
test/e2e/* Test suites modified to use the new SDK methods and types; account, bank account, connectors, payment initiation, payments, and pools tests updated for consistency.

Sequence Diagram(s)

sequenceDiagram
    participant Client
    participant Handler
    participant Utils as toV3PaymentScheme
    participant PaymentModel
    Client->>Handler: Send CreatePayment request (with Scheme)
    Handler->>Utils: Convert Scheme via toV3PaymentScheme()
    Utils-->>Handler: Return v3 scheme
    Handler->>PaymentModel: Initialize payment object (set Status)
    PaymentModel-->>Handler: Payment object created
    Handler-->>Client: Payment creation response returned
Loading

Possibly related PRs

Poem

I'm a rabbit, hopping with glee,
New schemas and types make my heart sing free.
Connectors reborn, enums laid to rest,
Payment flows now function at their best.
In code and tests, improvements bloom—
A joyous leap in our digital room!
🐇✨

✨ Finishing Touches
  • 📝 Generate Docstrings

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai plan to trigger planning for file edits and PR creation.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@codecov Codecov
Copy link
codecov bot commented Apr 8, 2025 •
edited
Loading

Codecov Report

Attention: Patch coverage is 11.11111% with 48 lines in your changes missing coverage. Please review.

Project coverage is 59.63%. Comparing base (cb23551) to head (1a577c4).
Report is 1 commits behind head on main.

Files with missing lines Patch % Lines
internal/api/v2/utils.go 7.69% 48 Missing ⚠️
Additional details and impacted files 
@@            Coverage Diff             @@
##             main     #401      +/-   ##
==========================================
- Coverage   59.71%   59.63%   -0.09%     
==========================================
  Files         538      538              
  Lines       26680    26734      +54     
==========================================
+ Hits        15933    15942       +9     
- Misses       9907     9953      +46     
+ Partials      840      839       -1

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@paul-nicolas paul-nicolas marked this pull request as ready for review April 8, 2025 13:27
@paul-nicolas paul-nicolas requested a review from a team as a code owner April 8, 2025 13:27
coderabbitai[bot]
coderabbitai bot reviewed Apr 8, 2025
View reviewed changes
Copy link
Contributor
@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (14)
pkg/client/models/operations/installconnector.go (1)

15-19: Document potential client impact of type system changes

While the getter implementation has been properly updated to use the new components.Connector type, consider documenting this API change for clients who may be affected by the migration from enum to string-based types.

Consider adding a comment to document that this change is part of a migration from ConnectorEnum to Connector:

+// GetConnector returns the Connector field value
+// Note: Type changed from ConnectorEnum to Connector as part of API refactoring
 func (o *InstallConnectorRequest) GetConnector() components.Connector {
 	if o == nil {
 		return components.Connector("")
 	}
 	return o.Connector
 }
pkg/client/models/components/connector.go (1)

29-61: Consider simplifying the UnmarshalJSON method implementation

While the current implementation with fallthrough works correctly, it could be simplified for better readability and maintainability:

func (e *Connector) UnmarshalJSON(data []byte) error {
	var v string
	if err := json.Unmarshal(data, &v); err != nil {
		return err
	}
-	switch v {
-	case "STRIPE":
-		fallthrough
-	case "DUMMY-PAY":
-		fallthrough
-	case "WISE":
-		fallthrough
-	case "MODULR":
-		fallthrough
-	case "CURRENCY-CLOUD":
-		fallthrough
-	case "BANKING-CIRCLE":
-		fallthrough
-	case "MANGOPAY":
-		fallthrough
-	case "MONEYCORP":
-		fallthrough
-	case "ATLAR":
-		fallthrough
-	case "ADYEN":
-		fallthrough
-	case "GENERIC":
-		*e = Connector(v)
-		return nil
-	default:
-		return fmt.Errorf("invalid value for Connector: %v", v)
-	}
+	// Define valid connectors
+	validConnectors := map[string]bool{
+		string(ConnectorStripe):        true,
+		string(ConnectorDummyPay):      true,
+		string(ConnectorWise):          true,
+		string(ConnectorModulr):        true,
+		string(ConnectorCurrencyCloud): true,
+		string(ConnectorBankingCircle): true,
+		string(ConnectorMangopay):      true,
+		string(ConnectorMoneycorp):     true,
+		string(ConnectorAtlar):         true,
+		string(ConnectorAdyen):         true,
+		string(ConnectorGeneric):       true,
+	}
+	
+	if validConnectors[v] {
+		*e = Connector(v)
+		return nil
+	}
+	
+	return fmt.Errorf("invalid value for Connector: %v, must be one of %v", v, 
+		[]string{string(ConnectorStripe), string(ConnectorDummyPay), string(ConnectorWise), 
+			string(ConnectorModulr), string(ConnectorCurrencyCloud), 
+			string(ConnectorBankingCircle), string(ConnectorMangopay), 
+			string(ConnectorMoneycorp), string(ConnectorAtlar), 
+			string(ConnectorAdyen), string(ConnectorGeneric)})
}
docs/api/README.md (1)

790-812: Consider clarifying required fields and default values.
These properties use "required": true and also specify a default value of "string". Providing a default for a required field can sometimes cause confusion — if the field is always required, a default might be redundant or might mask missing user input. Also, the property names (property1, property2) are generic. More descriptive names can improve readability and maintainability of the API documentation.

test/e2e/api_accounts_test.go (5)

49-50: Prefer local scope for test variables.
Declaring the e chan *nats.Msg variable at this package level when it’s only used within specific test blocks may reduce clarity. Consider moving it into closer scope (e.g., inside the relevant It or BeforeEach) to improve readability.

52-75: Good coverage in testing account creation (v2).
Your test steps (installing connector, creating account, fetching the result, verifying the event) look thorough. For even more robustness, consider adding negative test scenarios (e.g., creating an account with invalid parameters) or verifying edge cases like duplicate references.

77-100: Consider extracting repeated logic for v2/v3 tests.
The logic for creating and validating accounts in v3 mirrors that for v2. Factor out the repeated steps (e.g., subscribe, install connector, create, fetch) into helpers or shared functions to promote DRY principles and make it easier to maintain these test flows.

108-117: Ensure cleanup or reset of PSP data.
Within BeforeEach, the GeneratePSPData call sets up test data. If not already covered, ensure that ignoring or cleaning this data after each test is safe, preventing potential test interference in subsequent runs.

119-165: Comprehensive check of balances (v2).
The approach of polling for the SAVED_BALANCES event, unmarshaling the payload, and verifying against the fetched balances is good. Consider adding additional balance states or edge scenarios (e.g., zero balance, multiple assets) to broaden coverage further.

test/e2e/api_pools_test.go (4)

44-46: Group local variables together and document.
The block at lines 44-46 (connectorID, e, err) is straightforward, but adding a brief comment or docstring for each variable’s role in the test can improve clarity, especially for new contributors.

56-70: Validate error paths more thoroughly.
In the “should be ok when underlying accounts exist” test, you do a successful creation and fetch. Alongside success path coverage, consider verifying meaningful error states (like partial failures or invalid arguments) to ensure robust pool-handling logic.

109-113: Time-based checks can lead to flaky tests.
The test lines around installing the connector and waiting for subscription events rely on time-based approaches (Eventually with timeouts). This is often unavoidable, but keep an eye on potential flakes if the environment is slow. Having some buffer or ensuring repeated polling logic might help.

233-236: Duplicate references in pool operations.
The tests for adding/removing accounts from a pool do not fail even if the account is already present or absent. This is valid per your design. However, consider adding an explicit assertion that checks the logic is consistent with the user’s expectations (e.g., an idempotent API call) so the behavior remains clear to maintainers.

test/e2e/api_payments_test.go (1)

72-86: Check adjustments array for corner cases.
The creation of a payment with an adjustment is well covered. Consider adding more adjustments (e.g., multiple refunds) or exploring an edge case where the adjustment amount is greater than the payment amount, to confirm the behavior aligns with expected validations.

pkg/client/models/components/v3connectorconfigsresponse.go (1)

33-34: Nested map supports flexible structuring but consider using a custom type.

Having Data map[string]map[string]V3ConnectorConfigsResponseData supports flexible lookups. However, if the nesting grows complex, a type alias or more structured approach might simplify usage and ensure type safety in the future.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between cb23551 and 1a577c4.

⛔ Files ignored due to path filters (5)
  • go.mod is excluded by !**/*.mod
  • openapi.yaml is excluded by !**/*.yaml
  • openapi/v1- 8000 2/v1-2.yaml is excluded by !**/*.yaml
  • openapi/v3/v3-schemas.yaml is excluded by !**/*.yaml
  • pkg/client/.speakeasy/gen.lock is excluded by !**/*.lock, !**/*.lock
📒 Files selected for processing (60)
  • docs/api/README.md (3 hunks)
  • internal/api/v2/handler_payments_create.go (2 hunks)
  • internal/api/v2/utils.go (1 hunks)
  • internal/models/payment_scheme.go (1 hunks)
  • pkg/client/docs/models/components/bankaccountrequest.md (1 hunks)
  • pkg/client/docs/models/components/connector.md (1 hunks)
  • pkg/client/docs/models/components/connectorenum.md (0 hunks)
  • pkg/client/docs/models/components/connectorsconfigsresponse.md (1 hunks)
  • pkg/client/docs/models/components/connectorsconfigsresponseconnector.md (0 hunks)
  • pkg/client/docs/models/components/connectorsconfigsresponsedata.md (1 hunks)
  • pkg/client/docs/models/components/connectorsconfigsresponsekey.md (0 hunks)
  • pkg/client/docs/models/components/connectorsresponsedata.md (1 hunks)
  • pkg/client/docs/models/components/payment.md (1 hunks)
  • pkg/client/docs/models/components/v3connectorconfigsresponse.md (1 hunks)
  • pkg/client/docs/models/components/v3connectorconfigsresponseconnector.md (0 hunks)
  • pkg/client/docs/models/components/v3connectorconfigsresponsedata.md (1 hunks)
  • pkg/client/docs/models/components/v3connectorconfigsresponsekey.md (0 hunks)
  • pkg/client/docs/models/operations/connectorstransferrequest.md (1 hunks)
  • pkg/client/docs/models/operations/getconnectortaskrequest.md (1 hunks)
  • pkg/client/docs/models/operations/getconnectortaskv1request.md (1 hunks)
  • pkg/client/docs/models/operations/installconnectorrequest.md (1 hunks)
  • pkg/client/docs/models/operations/listconnectortasksrequest.md (1 hunks)
  • pkg/client/docs/models/operations/listconnectortasksv1request.md (1 hunks)
  • pkg/client/docs/models/operations/readconnectorconfigrequest.md (1 hunks)
  • pkg/client/docs/models/operations/readconnectorconfigv1request.md (1 hunks)
  • pkg/client/docs/models/operations/resetconnectorrequest.md (1 hunks)
  • pkg/client/docs/models/operations/resetconnectorv1request.md (1 hunks)
  • pkg/client/docs/models/operations/uninstallconnectorrequest.md (1 hunks)
  • pkg/client/docs/models/operations/uninstallconnectorv1request.md (1 hunks)
  • pkg/client/docs/models/operations/updateconnectorconfigv1request.md (1 hunks)
  • pkg/client/docs/sdks/v1/README.md (27 hunks)
  • pkg/client/models/components/bankaccountrequest.go (2 hunks)
  • pkg/client/models/components/connector.go (1 hunks)
  • pkg/client/models/components/connectorenum.go (0 hunks)
  • pkg/client/models/components/connectorsconfigsresponse.go (1 hunks)
  • pkg/client/models/components/connectorsresponse.go (1 hunks)
  • pkg/client/models/components/payment.go (2 hunks)
  • pkg/client/models/components/v3connectorconfigsresponse.go (1 hunks)
  • pkg/client/models/operations/connectorstransfer.go (1 hunks)
  • pkg/client/models/operations/getconnectortask.go (1 hunks)
  • pkg/client/models/operations/getconnectortaskv1.go (1 hunks)
  • pkg/client/models/operations/installconnector.go (1 hunks)
  • pkg/client/models/operations/listconnectortasks.go (2 hunks)
  • pkg/client/models/operations/listconnectortasksv1.go (2 hunks)
  • pkg/client/models/operations/readconnectorconfig.go (1 hunks)
  • pkg/client/models/operations/readconnectorconfigv1.go (1 hunks)
  • pkg/client/models/operations/resetconnector.go (1 hunks)
  • pkg/client/models/operations/resetconnectorv1.go (1 hunks)
  • pkg/client/models/operations/uninstallconnector.go (1 hunks)
  • pkg/client/models/operations/uninstallconnectorv1.go (1 hunks)
  • pkg/client/models/operations/updateconnectorconfigv1.go (1 hunks)
  • pkg/client/v1.go (13 hunks)
  • pkg/testserver/api.go (0 hunks)
  • test/e2e/api_accounts_test.go (2 hunks)
  • test/e2e/api_bank_accounts_test.go (5 hunks)
  • test/e2e/api_connectors_test.go (16 hunks)
  • test/e2e/api_payment_initiations_test.go (6 hunks)
  • test/e2e/api_payments_test.go (2 hunks)
  • test/e2e/api_pools_test.go (2 hunks)
  • test/e2e/suite_test.go (1 hunks)
💤 Files with no reviewable changes (7)
  • pkg/client/docs/models/components/v3connectorconfigsresponsekey.md
  • pkg/client/docs/models/components/connectorsconfigsresponsekey.md
  • pkg/client/docs/models/components/connectorsconfigsresponseconnector.md
  • pkg/client/docs/models/components/v3connectorconfigsresponseconnector.md
  • pkg/testserver/api.go
  • pkg/client/docs/models/components/connectorenum.md
  • pkg/client/models/components/connectorenum.go
🧰 Additional context used
🧬 Code Definitions (18)
internal/api/v2/utils.go (1)
internal/models/payment_scheme.go (24)
  • PAYMENT_SCHEME_UNKNOWN (14-14)
  • PAYMENT_SCHEME_OTHER (43-43)
  • PAYMENT_SCHEME_CARD_VISA (16-16)
  • PAYMENT_SCHEME_CARD_MASTERCARD (17-17)
  • PAYMENT_SCHEME_CARD_AMEX (18-18)
  • PAYMENT_SCHEME_CARD_DINERS (19-19)
  • PAYMENT_SCHEME_CARD_DISCOVER (20-20)
  • PAYMENT_SCHEME_CARD_JCB (21-21)
  • PAYMENT_SCHEME_CARD_UNION_PAY (22-22)
  • PAYMENT_SCHEME_CARD_ALIPAY (23-23)
  • PAYMENT_SCHEME_CARD_CUP (24-24)
  • PAYMENT_SCHEME_SEPA_DEBIT (26-26)
  • PAYMENT_SCHEME_SEPA_CREDIT (27-27)
  • PAYMENT_SCHEME_SEPA (28-28)
  • PAYMENT_SCHEME_APPLE_PAY (31-31)
  • PAYMENT_SCHEME_GOOGLE_PAY (30-30)
  • PAYMENT_SCHEME_DOKU (33-33)
  • PAYMENT_SCHEME_DRAGON_PAY (34-34)
  • PAYMENT_SCHEME_MAESTRO (35-35)
  • PAYMENT_SCHEME_MOL_PAY (36-36)
  • PAYMENT_SCHEME_A2A (38-38)
  • PAYMENT_SCHEME_ACH_DEBIT (39-39)
  • PAYMENT_SCHEME_ACH (40-40)
  • PAYMENT_SCHEME_RTP (41-41)
pkg/client/models/operations/getconnectortask.go (2)
pkg/client/models/components/connector.go (1)
  • Connector (10-10)
internal/models/task_id.go (1)
  • TaskID (12-15)
pkg/client/models/operations/resetconnector.go (1)
pkg/client/models/components/connector.go (1)
  • Connector (10-10)
pkg/client/models/operations/updateconnectorconfigv1.go (1)
pkg/client/models/components/connector.go (1)
  • Connector (10-10)
pkg/client/models/operations/installconnector.go (1)
pkg/client/models/components/connector.go (1)
  • Connector (10-10)
pkg/client/models/operations/listconnectortasks.go (1)
pkg/client/models/components/connector.go (1)
  • Connector (10-10)
pkg/client/models/operations/listconnectortasksv1.go (1)
pkg/client/models/components/connector.go (1)
  • Connector (10-10)
pkg/client/models/operations/resetconnectorv1.go (1)
pkg/client/models/components/connector.go (1)
  • Connector (10-10)
pkg/client/models/operations/readconnectorconfigv1.go (1)
pkg/client/models/components/connector.go (1)
  • Connector (10-10)
pkg/client/models/components/payment.go (1)
pkg/client/models/components/connector.go (1)
  • Connector (10-10)
pkg/client/models/operations/connectorstransfer.go (1)
pkg/client/models/components/connector.go (1)
  • Connector (10-10)
pkg/client/models/operations/uninstallconnectorv1.go (1)
pkg/client/models/components/connector.go (1)
  • Connector (10-10)
pkg/client/models/operations/readconnectorconfig.go (1)
pkg/client/models/components/connector.go (1)
  • Connector (10-10)
pkg/client/models/operations/uninstallconnector.go (1)
pkg/client/models/components/connector.go (1)
  • Connector (10-10)
test/e2e/api_pools_test.go (4)
pkg/testserver/helpers.go (1)
  • Subscribe (30-39)
test/e2e/suite_test.go (1)
  • GenericEventPayload (43-45)
pkg/events/event.go (2)
  • EventTypeSavedPool (9-9)
  • EventTypeDeletePool (10-10)
pkg/testserver/server.go (1)
  • Server (61-71)
test/e2e/api_accounts_test.go (6)
pkg/testserver/helpers.go (1)
  • Subscribe (30-39)
pkg/client/v1.go (1)
  • V1 (20-22)
pkg/events/event.go (2)
  • EventTypeSavedAccounts (12-12)
  • EventTypeSavedBalances (13-13)
pkg/client/v3.go (1)
  • V3 (20-22)
internal/events/balance.go (1)
  • BalanceMessagePayload (12-20)
pkg/testserver/server.go (1)
  • Server (61-71)
test/e2e/api_payment_initiations_test.go (5)
pkg/client/v3.go (1)
  • V3 (20-22)
internal/models/tasks.go (2)
  • TASK_STATUS_SUCCEEDED (15-15)
  • TASK_STATUS_FAILED (16-16)
internal/models/payment_initiation_adjusments_status.go (3)
  • PAYMENT_INITIATION_ADJUSTMENT_STATUS_PROCESSED (16-16)
  • PAYMENT_INITIATION_ADJUSTMENT_STATUS_REJECTED (18-18)
  • PAYMENT_INITIATION_ADJUSTMENT_STATUS_REVERSED (21-21)
internal/connectors/engine/workflow/reverse.go (1)
  • ErrPaymentInitiationNotProcessed (17-17)
pkg/events/event.go (1)
  • EventTypeSavedPayments (11-11)
test/e2e/api_payments_test.go (2)
internal/models/payment_scheme.go (1)
  • PAYMENT_SCHEME_CARD_AMEX (18-18)
pkg/events/event.go (2)
  • EventTypeSavedPayments (11-11)
  • EventTypeSavedAccounts (12-12)
🪛 GitHub Check: codecov/patch
internal/api/v2/utils.go

[warning] 202-249: internal/api/v2/utils.go#L202-L249
Added lines #L202 - L249 were not covered by tests

🔇 Additional comments (144)
test/e2e/suite_test.go (1)

13-19: Import reorganization looks good.

The changes reorder the import statement for the deferred package and add a blank line after the import block, improving readability. This is a good practice for organizing imports.

pkg/client/docs/models/components/connector.md (1)

1-18: Well-structured connector documentation.

This is a clear and concise documentation of the connector types and their corresponding values. The table format makes it easy to reference each connector and its value.

pkg/client/docs/sdks/v1/README.md (3)

1373-1373: Improved type safety with client.String wrapper.

Using client.String("<id>") instead of a raw string improves type safety and makes the API more consistent.

1753-1753: Type change from ConnectorEnum to Connector.

This change is part of the broader migration from ConnectorEnum to the more general Connector type.

1814-1814: Consistent type update across connector functions.

The type changes from ConnectorEnum to Connector are applied consistently across all connector-related functions, maintaining API coherence.

Also applies to: 1923-1923, 2094-2094, 2205-2205, 2260-2260, 2318-2318, 2372-2372, 2428-2428

pkg/client/docs/models/operations/listconnectortasksv1request.md (1)

8-8: Updated type reference in documentation.

The Connector field type has been updated from ConnectorEnum to Connector, aligning with the broader changes across the codebase.

internal/models/payment_scheme.go (1)

43-43: Improved type safety for PAYMENT_SCHEME_OTHER constant.

Explicitly typing PAYMENT_SCHEME_OTHER as PaymentScheme = 100 rather than just = 100 enhances type safety and code clarity. This is particularly important for constants that are part of a type system.

pkg/client/docs/models/operations/installconnectorrequest.md (1)

8-8: Connector Type Reference Updated
The Connector field now references [components.Connector](../../models/components/connector.md) instead of the old enumeration. This change is consistent with the broader API refactor and improves clarity in the documentation.

pkg/client/docs/models/operations/connectorstransferrequest.md (1)

8-8: Connector Field Type Changed Consistently
The updated type [components.Connector](../../models/components/connector.md) for the Connector field aligns with similar updates across the documentation. This ensures consistency in how connectors are represented across operations.

pkg/client/docs/models/components/connectorsresponsedata.md (1)

8-8: Updated Provider Field Type
The Provider field now uses [components.Connector](../../models/components/connector.md), harmonizing its definition with the new connector type being adopted elsewhere. This reinforces consistency and improves the documentation's accuracy.

pkg/client/docs/models/operations/updateconnectorconfigv1request.md (1)

8-8: Revised Connector Field in UpdateConnectorConfigV1Request
The Connector field now properly references [components.Connector](../../models/components/connector.md). This update is in line with the overall refactoring efforts and ensures that the documentation reflects the current implementation accurately.

pkg/client/docs/models/operations/listconnectortasksrequest.md (1)

8-8: Consistent Connector Field Update
The change to [components.Connector](../../models/components/connector.md) for the Connector field in ListConnectorTasksRequest is correct and consistent with the other refactored documentation. This update helps maintain a unified type representation across the API documentation.

pkg/client/docs/models/operations/readconnectorconfigrequest.md (1)

6-8: Updated Connector Field Type and Formatting

The header row in the fields table has been reformatted for better clarity, and the Connector field type has been updated to reference [components.Connector](../../models/components/connector.md), aligning this model with the new definitions.

pkg/client/docs/models/components/payment.md (1)

13-13: Updated Provider Field Type

The Provider field type has been changed from using the enumerated type to [*components.Connector](../../models/components/connector.md). This change brings enhanced flexibility and consistency with the corresponding model updates.

pkg/client/docs/models/operations/resetconnectorrequest.md (1)

6-8: Revised Connector Field Documentation

The Connector field now correctly references [components.Connector](../../models/components/connector.md) with improved table formatting. This update is consistent with the overall migration away from ConnectorEnum.

pkg/client/docs/models/operations/uninstallconnectorrequest.md (1)

6-8: Consistent Update to Connector Field

The documentation for UninstallConnectorRequest has been updated to display the new connector type [components.Connector](../../models/components/connector.md). The improved formatting further ensures clarity.

pkg/client/docs/models/operations/getconnectortaskv1request.md (1)

6-10: Refined Field Documentation and Type Update

The fields table in GetConnectorTaskV1Request has been updated to reflect the new Connector type, now documented as [components.Connector](../../models/components/connector.md). Additionally, the overall formatting—including the header and accompanying descriptive columns—is now cleaner. The inclusion of fields like ConnectorID and TaskID further clarifies the model's structure.

pkg/client/docs/models/operations/uninstallconnectorv1request.md (1)

6-8: Documentation updated correctly for the new Connector type

The field type for Connector has been properly updated from ConnectorEnum to the more general Connector type, aligning with the broader refactoring across the codebase. Table formatting also looks good.

internal/api/v2/handler_payments_create.go (2)

48-48: Payment scheme normalization added before validation

Adding the conversion to standardize payment scheme values before validation ensures consistent scheme handling across the API, regardless of how clients format the input scheme.

82-82: Payment status now explicitly set in the model

Good addition. Explicitly setting the status field in the payment object from the validated status value ensures the payment status is correctly reflected in the created payment.

pkg/client/docs/models/components/connectorsconfigsresponse.md (1)

8-10: Data type updated to nested map structure

The type definition update from a simple reference to a nested map structure (map[string]map[string][components.ConnectorsConfigsResponseData]) correctly reflects the restructuring of connector configurations in the JSON schema.

internal/api/v2/utils.go (1)

200-253:

❓ Verification inconclusive

New utility function added for payment scheme conversion

The toV3PaymentScheme function correctly maps string representations to their model constants, complementing the existing toV2PaymentScheme function. This ensures consistent payment scheme handling throughout the codebase.

The function is currently not covered by tests according to the codecov report. Consider adding unit tests to verify all payment scheme conversions:

🏁 Script executed:

#!/bin/bash
# Search for existing tests of the toV2PaymentScheme function to use as a reference
rg -A 5 "Test.*toV2PaymentScheme" --type go

Length of output: 45

ACTION: Add unit tests for new payment scheme conversion

The toV3PaymentScheme function appears to correctly map input strings to their corresponding model constants, mirroring the behavior of the existing toV2PaymentScheme function. However, our automated search for tests (using the provided rg command) did not return any reference tests for toV2PaymentScheme. This absence may suggest that unit tests for payment scheme conversions are either missing or not easily locatable. Please manually verify the test coverage for payment scheme conversions in the codebase. In any case, consider adding comprehensive unit tests for toV3PaymentScheme to ensure that every payment scheme is correctly handled. You might use the existing tests for toV2PaymentScheme as inspiration if they exist.

  • File: internal/api/v2/utils.go (lines 200–253)
  • Recommendation: Add unit tests covering all string inputs to ensure each conversion returns the expected model constant.
  • Next Step: Manually verify whether similar tests for toV2PaymentScheme exist; if not, introduce tests for both functions to maintain consistency.
🧰 Tools
🪛 GitHub Check: codecov/patch

[warning] 202-249: internal/api/v2/utils.go#L202-L249
Added lines #L202 - L249 were not covered by tests

pkg/client/docs/models/components/v3connectorconfigsresponse.md (1)

6-8: Documentation correctly reflects API structure changes

The updated type for the Data field from a single reference to a nested map structure (map[string]map[string][components.V3ConnectorConfigsResponseData]) aligns with the pull request's broader restructuring of connector configurations. This change improves the representation of hierarchical configuration data.

pkg/client/docs/models/operations/resetconnectorv1request.md (1)

6-9: Type change aligns with connector model refactoring

The update from ConnectorEnum to Connector reflects the broader transition away from enumerated types toward more general connector representations, which is consistent with the pull request's overall goals. The improved table formatting also enhances readability.

pkg/client/docs/models/components/v3connectorconfigsresponsedata.md (1)

6-10: Model restructured with improved metadata fields

The V3ConnectorConfigsResponseData model has been significantly refactored:

  • Removed Connector field
  • Added detailed metadata fields (DataType, Required, DefaultValue)

This change enhances the model's ability to describe configuration parameters with proper typing and requirements information, which improves type safety and validation capabilities.

pkg/client/docs/models/components/connectorsconfigsresponsedata.md (1)

6-10: Consistent model restructuring with v3 version

The ConnectorsConfigsResponseData model has been updated with the same pattern as V3ConnectorConfigsResponseData:

  • Removed Connector field
  • Added the same metadata fields (DataType, Required, DefaultValue)

This consistency between different API versions ensures a unified approach to connector configuration representation throughout the codebase.

pkg/client/models/components/connectorsresponse.go (2)

6-7: Type updated from ConnectorEnum to Connector

The Provider field type has been updated from the more restrictive ConnectorEnum to the more general Connector type, aligning with the broader refactoring of connector representations across the codebase.

12-16: GetProvider method properly updated to match field type change

The GetProvider method has been correctly updated to return the new Connector type instead of ConnectorEnum, with appropriate handling of the nil case. This ensures type consistency between fields and their accessor methods.

pkg/client/models/operations/connectorstransfer.go (2)

11-11: Connector field type updated from ConnectorEnum to Connector

The Connector field in ConnectorsTransferRequest has been updated to use the more general components.Connector type instead of the previously used enumeration type. This follows the consistent pattern of refactoring across the codebase.

15-18: GetConnector method updated to match field type

The GetConnector method has been properly updated to return the new components.Connector type and provides an appropriate default value when the receiver is nil. This ensures consistency with the field type change in the struct.

pkg/client/docs/models/operations/getconnectortaskrequest.md (1)

6-9: Documentation successfully updated with new type definition

The updated documentation correctly reflects the migration from ConnectorEnum to Connector type, while also improving the table formatting.

pkg/client/models/operations/getconnectortaskv1.go (2)

11-11: Type successfully updated to use the new Connector type

The field type has been correctly changed from ConnectorEnum to Connector, aligning with the project-wide type standardization.

18-21: GetConnector method signature and implementation properly updated

The method signature and its default return value have been updated to use the new Connector type, maintaining consistency with the field declaration.

pkg/client/models/operations/resetconnector.go (2)

11-11: Type successfully updated to use the new Connector type

The field type has been correctly changed from ConnectorEnum to Connector, maintaining consistency with the refactoring in other files.

14-17: GetConnector method signature and implementation properly updated

The method signature and its default return value have been appropriately updated to use the new Connector type, ensuring type consistency across the codebase.

pkg/client/models/operations/listconnectortasksv1.go (2)

12-12: Type successfully updated to use the new Connector type

The field type has been correctly changed from ConnectorEnum to Connector, consistent with the codebase-wide migration.

37-40: GetConnector method signature and implementation properly updated

The method signature and its default return value have been properly updated to use the new Connector type, ensuring consistency across the codebase.

pkg/client/models/operations/uninstallconnectorv1.go (2)

11-11: Type change from ConnectorEnum to Connector is consistent with the project refactoring.

The change from components.ConnectorEnum to components.Connector aligns with the project's move toward a simpler string representation instead of an enumeration. This provides more flexibility when adding new connector types.

16-18: Method signature update is consistent with field type change.

The return type update from components.ConnectorEnum to components.Connector and the corresponding change in the nil case handling maintain API consistency with the field type change.

pkg/client/models/operations/resetconnectorv1.go (2)

11-11: Type change is consistent with the connector refactoring.

The change from components.ConnectorEnum to components.Connector follows the same pattern as in other files, maintaining consistency in the API.

16-18: Method signature update correctly reflects the type change.

The return type and empty value initialization have been properly updated to match the Connector field type.

pkg/client/models/operations/getconnectortask.go (2)

11-11: Connector type update matches the project-wide refactoring.

This change from components.ConnectorEnum to components.Connector is consistent with other request structures in the codebase.

16-18: Method signature and implementation correctly updated.

The return type update and empty value initialization are properly aligned with the field type change.

pkg/client/models/operations/updateconnectorconfigv1.go (3)

11-11: Type change is consistent with the connector model refactoring.

The change from components.ConnectorEnum to components.Connector aligns with other files in the PR, promoting a more flexible representation of connectors.

17-19: Method signature and implementation properly updated.

The return type has been correctly changed to match the field type, and the empty value initialization is consistent.

38-80: Ensure all getter methods are compatible with the new Connector type.

These connector-specific getter methods appear unaffected by the change from ConnectorEnum to Connector. The implementation correctly relies on the GetConnectorConfig() method which returns the entire config structure.

pkg/client/models/operations/listconnectortasks.go (2)

35-38: Align return type with field type change

The return type update from components.ConnectorEnum to components.Connector correctly maintains consistency with the field type change. This is a good practice for ensuring API coherence.

12-12:

❓ Verification inconclusive

Verify that this type change is backward compatible

Changing components.ConnectorEnum to components.Connector represents a shift from an enum type to a string type. While this provides more flexibility, it could potentially reduce type safety if client code relied on the enum's restricted set of values.

🏁 Script executed:

#!/bin/bash
# Check all usage of the Connector field to ensure compatibility
grep -r "ConnectorEnum" --include="*.go" .

Length of output: 42

Manual Verification Required: Ensure Backward Compatibility for Connector Type

The grep output for "ConnectorEnum" returned no results, suggesting that the legacy enum is no longer referenced. However, since changing from an enum to a string may affect client logic relying on the fixed set of enum values, please manually verify that:

  • All client code using the Connector field correctly handles it as a string.
  • Validation, serialization, or comparisons that previously depended on enum restrictions are updated to match the new type.
  • Integration and unit tests covering these interactions pass without issues.
pkg/client/models/operations/readconnectorconfigv1.go (2)

11-11: Type modification aligns with global refactoring pattern

Changing from components.ConnectorEnum to components.Connector is consistent with the pattern observed across the codebase. This helps maintain a unified approach to connector types.

16-19: Ensure consistent error handling with type change

The update to return components.Connector("") instead of components.ConnectorEnum("") maintains the same error handling pattern while adapting to the new type. This is a good approach to preserving behavior during refactoring.

pkg/client/models/operations/readconnectorconfig.go (1)

11-11: Consistent type migration across request structures

The changes to both the field type and the getter method maintain consistency with the codebase-wide migration from ConnectorEnum to Connector type. The default empty string value pattern is preserved, which is good for maintaining behavioral compatibility.

Also applies to: 14-17

pkg/client/models/operations/installconnector.go (1)

11-11: Type change maintains struct layout while updating type system

The change from components.ConnectorEnum to components.Connector preserves the struct's field organization while integrating with the new type system. The struct tag remains unchanged, which is appropriate since the serialization behavior should be consistent.

pkg/client/models/operations/uninstallconnector.go (2)

11-11: Type change looks good: ConnectorEnum → Connector

The change from ConnectorEnum to Connector aligns with the broader refactoring across the codebase to use a more flexible string-based type.

14-17: Method return type and default value correctly updated

The getter method's return type has been properly updated to match the field type change, and the nil-case handling correctly returns an empty string of the new type.

pkg/client/docs/models/components/bankaccountrequest.md (1)

9-14:

✅ Verification successful

Verify the type notation and field requirement changes

The type notation has changed from *string* to **string* for multiple fields, which looks unusual. In Go, a pointer to a pointer would typically be written as **string without the trailing asterisk.

Also, several fields that were previously required are now optional. Please confirm this aligns with the intended API contract changes.

🏁 Script executed:

#!/bin/bash
# Check for similar notation in other documentation files
# to verify if this is a consistent pattern

echo "Checking for **string* notation in other markdown files:"
fd -e md . pkg/client/docs/models/ | xargs grep -l "\*\*string\*" | head -n 5

echo -e "\nChecking the actual type definitions in the Go code:"
fd -e go . pkg/client/models/components/ | xargs grep -A 2 "BankAccountRequest struct"

Length of output: 1864

API Field Notation and Field Requirement Changes Confirmed

The use of the "*string" notation in the markdown files is consistent across the documentation (e.g., in other model files like account.md and accountrequest.md) and is intentionally used to indicate optional fields. Our review of the corresponding Go code confirms that fields such as ConnectorID and AccountNumber are defined as pointers (e.g., *string) with the omitempty tag, meaning they are optional, while required fields like Name use the non-pointer type. Although the markdown notation may look unusual compared to typical Go syntax, it is a deliberate formatting choice rather than a pointer-to-pointer error.

pkg/client/models/components/connector.go (1)

10-28: Good implementation of the Connector type with helper method

The new Connector string type with predefined constants is a good approach. The ToPointer() method is a useful helper for working with the value as a pointer.

test/e2e/api_bank_accounts_test.go (7)

9-14: Updated imports align with the refactoring changes

The new imports for pointer utilities and components package are appropriate for the code changes.

30-32: Variable type changes properly reflect the new API structure

The update from using versioned request types to the new component-based types is consistent with the broader refactoring approach.

47-52: Proper use of pointers for optional fields

The use of pointer utility functions for optional fields is a good practice. The field name change from IBAN to Iban follows Go naming conventions.

54-59: Consistent field naming between v2 and v3 requests

The field naming is consistent between the v2 and v3 request structures, with the only difference being how optional fields are handled (direct string vs pointer).

66-68: Updated SDK method calls and response handling

The test now correctly uses the new SDK methods and properly accesses the response data through the appropriate getter methods.

119-122: Consistent error checking for invalid connector IDs

The test properly checks for error cases with invalid connector IDs using the updated request structures.

Also applies to: 190-193, 197-200

225-228: Clean implementation of metadata update tests

The metadata update tests correctly use the new request structures and perform appropriate validation of the responses.

test/e2e/api_payments_test.go (1)

44-49: Good practice setting test data upfront.
Defining createdAt, initialAmount, and asset near the top of the test helps ensure clarity. Just ensure to keep them updated or re-initialized in each test if any concurrency or test-state pollution might occur.

test/e2e/api_payment_initiations_test.go (36)

8-9: Added pointer and deferred imports
These appear valid for handling pointer references and deferred logic in tests.

12-12: Importing the components package
This import is needed for the V3 request/response types.

48-51: Refactoring local variables
Introducing debtorID, creditorID, payReq, and paymentInitiationID as separate fields clarifies the test logic and keeps variable usage clear.

53-53: New local variable connectorID
Storing the connector ID in a dedicated variable keeps code more organized for repeated usage.

58-58: Installing connector with version=3
Good call to a unified install function. The error handling is appropriate with the Expect(err).To(BeNil()) assertion.

61-62: Setting up V3 accounts and payment request
Invoking setupDebtorAndCreditorV3Accounts and building V3InitiatePaymentRequest helps keep v3 logic in one place. Clear and consistent.

74-79: Initiating payment and verifying response
Using pointer.For(false) toggles PSP behavior. Checking that TaskID is empty and PaymentInitiationID is set ensures correct logic for local (non-PSP) flows.

90-93: Approving payment initiation
The test properly validates that the approval returns a valid outcome, with a correct task reference.

102-102: Setting connector ID in JSON payload
Populating ConnectorID in the event payload ensures proper traceability and filtering in subsequent checks.

122-122: Poll for task completion
Reasonable approach with a 5-second timeout for the task poller. Ensures asynchronous flows finish before test validation.

124-126: Get and verify final status
Checks that the payment status is updated to PROCESSED. Confirms the initiation flow is end-to-end functional.

130-133: Rejecting payment
Call to RejectPaymentInitiation followed by a status check ensures that rejections propagate correctly.

Also applies to: 136-136

140-141: Reversal of unprocessed payment
Demonstrates error scenario; expecting a failed task with ErrPaymentInitiationNotProcessed. Great negative test coverage.

Also applies to: 146-146, 150-150

154-154: Approving payment prior to reversal
Makes sense to approve first to simulate a processed payment scenario.

162-162: Connector ID included in event payload
Reinforces connector traceability in the subsequent saved payment events.

168-168: Ensure successful final task status
Verifies that the payment hits a successful state before proceeding.

170-170: ReversePaymentInitiation call
Building the reverse request is straightforward; good to see metadata included for traceability.

Also applies to: 176-176

178-180: Block until workflow completes and poll
Combines blocking on the internal workflow and verifying final task status, making the test robust.

182-182: Reversed status check
Confirms that the payment is truly reversed, finishing the scenario.

Also applies to: 184-184

193-196: New payout scenario variables
Defines a second scenario for payouts using the same approach as transfers. Good test coverage across use cases.

Also applies to: 198-198

203-203: Building a payout request
Mirrors the TRANSFER approach but sets Type to "PAYOUT". This is consistent with the new API.

Also applies to: 206-207, 209-209, 211-211

219-224: Initiating payout
Checks that TaskID is empty and PaymentInitiationID is set, confirming the same local approach as with transfers.

228-228: Approving payout
Ensures the creation of a task ID referencing "create-payout", consistent with naming for actions in this domain.

Also applies to: 230-231

240-240: Connector ID in event payload
Aligns with the overall approach of verifying events.

246-246: Wait for payout task
Checks for TASK_STATUS_SUCCEEDED. Mirrors the process test.

248-248: Confirm final payout status
Ensures the payout is marked PROCESSED.

Also applies to: 250-250

254-254: Reject payout
Same logic as rejecting a transfer, ensuring coverage across multiple flows.

Also applies to: 257-257, 259-259

263-264: Attempting to reverse an unprocessed payout
Consistently triggers ErrPaymentInitiationNotProcessed. Nice coverage for negative cases.

Also applies to: 269-269

271-271: Verifying failed reversal task
Ensures the workflow accurately signals a failed reversal for unprocessed payouts.

Also applies to: 273-273

277-277: Approve payout
Again, consistent pre-reversal scenario.

285-285: Recording connector ID
Keeps test output consistent.

291-291: Wait for approval task success
Ensuring completion prior to next action is a best practice in asynchronous test flows.

293-293: Reversing an approved payout
Covers the alternate path where the payment is processed, ensuring reversal workflow success.

Also applies to: 299-299, 301-303

305-307: Verify reversed payout status
Ensures the final state is REVERSED - matches expectations.

370-401: Detailed config checks for v3
Comprehensive verification of connector config fields (pageSize, pollingPeriod, etc.). The repeated step of parsing defaults ensures robust coverage. Looks good.

403-435: Detailed config checks for v2
Mirrors the v3 checks for backward compatibility. This ensures consistent config fields across versions.

test/e2e/api_connectors_test.go (15)

14-14: Added pointer import
This import is used for setting default or optional config fields, improving code simplicity.

105-122: DescribeTable for invalid plugin-side config
This block systematically tests config validation errors for both v2 and v3. The approach provides good coverage and clarity for negative cases.

145-145: Installing a connector with v2
Switching to installV2Connector demonstrates correct version-based logic.

163-163: Using installed connector ID
Ensures that subsequent updates reference the correct connector.

167-167: Reading config after updates
Confirms the newly updated config persists and matches expectations.

257-257: Connector uninstall with v3
Verifies uninstallation tasks, ensuring cleanliness of the environment.

263-263: Reversal snippet not found here

Also applies to: 264-264, 269-269

271-271: Reversal snippet not found here

Also applies to: 273-273

327-327: Scheduling references

334-335: Scheduling references

472-476: installConnector function
This function orchestrates installing connectors across versions, returning a connector ID. The switch on ver properly delegates to v2 or v3 logic.

Also applies to: 477-483

485-501: installV3Connector function
Nicely encapsulates the v3 installation process. Ensures fallback to a default config if none is provided.

503-519: installV2Connector function
Similar logic for v2 connectors, with consistent fallback to a default config. Good separation of concerns.

521-537: newV3ConnectorConfigFn
Generates a realistic v3 dummyPay config with temporary directories. The cleanup logic is a nice safeguard.

539-554: newV2ConnectorConfigFn
Provides a parallel function for v2 dummyPay configurations. Good that it mirrors the v3 approach and cleans temp dirs.

pkg/client/models/components/connectorsconfigsresponse.go (6)

5-9: New fields in ConnectorsConfigsResponseData
Defining DataType, Required, and DefaultValue clarifies how connector configurations are documented and validated.

11-16: Getter for DataType
Graceful handling when o is nil, returning an empty string.

18-23: Getter for Required
Similarly, ensures no panic on nil pointer.

25-30: Getter for DefaultValue
Safely returns a *string, preventing nil-pointer exceptions.

34-34: Data map restructured
Using map[string]map[string]ConnectorsConfigsResponseData increases flexibility for multiple connectors and fields.

37-42: GetData() usage
Returns an empty map when struct is nil, ensuring no unexpected nil references.

pkg/client/models/components/v3connectorconfigsresponse.go (5)

5-9: Struct design looks good.

The addition of DataType, Required, and DefaultValue fields provides clarity and flexibility for handling connector configurations. Using a pointer for DefaultValue helps distinguish between the absence of a default and an empty string, ensuring correctness in JSON serialization with omitempty.

18-23: Safe default for a missing object.

Returning false by default is logical for GetRequired() since nil means no requirement data available, translating naturally to "not required."

25-30: Optional field handling is appropriate.

The pointer-based approach in GetDefaultValue() correctly differentiates between the absence of a default value and an empty string. This design is consistent and clear.

36-41: Return of an empty nested map is appropriate.

GetData() returning an empty map helps avoid nil checks downstream. This approach follows a reasonable best practice to reduce the chance of runtime nil-map assignments.

11-16:

✅ Verification successful

Consider returning an explicit error or default indicator.

Currently, GetDataType() returns an empty string when o is nil. This may be acceptable as a safe default but verify that downstream logic doesn't mistakenly treat an empty string the same as a defined dataType.

Would you like to confirm via code search that no downstream logic treats an empty string as a valid or special dataType?

🏁 Script executed:

#!/bin/bash
# We'll search references to GetDataType and see how they're used
rg -A 3 'GetDataType'

Length of output: 679

Downstream Usage Confirmed
After reviewing the code, both instances of GetDataType() in:

  • pkg/client/models/components/v3connectorconfigsresponse.go
  • pkg/client/models/components/connectorsconfigsresponse.go

return an empty string when o is nil, as a safe default. Our code search did not reveal any downstream logic that treats an empty string as a valid or special dataType. Given these findings, the current implementation appears acceptable. However, remain mindful that future changes to the codebase might require handling nil receivers more explicitly.

pkg/client/v1.go (13)

6558-6783: Type migration from ConnectorEnum to Connector improves flexibility

The InstallConnector method signature has been updated to use components.Connector instead of the previous components.ConnectorEnum. This change aligns with the broader refactoring effort across the codebase to move from a restrictive enum type to a more general connector type, providing better flexibility and extensibility for connector implementations.

6789-7188: Type migration applied to deprecated UninstallConnector method

This deprecated method has been updated to use the new components.Connector type for consistency with the rest of the codebase. While the method is marked for removal in a future release, the type change ensures consistency during the transition period.

6990-7186: Update to UninstallConnectorV1 method improves type safety

The UninstallConnectorV1 method now uses the more flexible components.Connector type instead of ConnectorEnum. This change is part of the package-wide migration to improve type safety and extensibility in the connector handling system.

7194-7411: Deprecated ReadConnectorConfig method updated for type consistency

The ReadConnectorConfig method has been updated to use components.Connector while maintaining its deprecated status. This change ensures type consistency across the API during the transition period.

7415-7843: UpdateConnectorConfigV1 method signature updated to use new Connector type

The signature change from ConnectorEnum to Connector maintains API consistency while providing more flexibility in connector configuration handling. The implementation remains unchanged, focusing solely on the type update.

7850-8047: Type migration for deprecated ResetConnector method

Though marked for deprecation, the ResetConnector method has been updated to use the new components.Connector type, ensuring consistent typing across the package until this method is removed in a future release.

8052-8249: ResetConnectorV1 method updated to new Connector type

The ResetConnectorV1 method signature has been modified to use components.Connector type, aligning with the broader refactoring effort to improve type flexibility in connector handling.

8256-8480: Type update in deprecated ListConnectorTasks method

This deprecated method has been updated to use components.Connector while maintaining backward compatibility. The implementation remains unchanged, focusing solely on the type migration.

8483-8707: ListConnectorTasksV1 method updated to use the new Connector type

The method now accepts components.Connector instead of ConnectorEnum, improving API flexibility while maintaining the same functionality. This change is consistent with the package-wide type migration.

8713-8931: GetConnectorTask method updated for type consistency

Although deprecated, the GetConnectorTask method has been updated to use the new components.Connector type to ensure API consistency during the transition period.

8935-9154: GetConnectorTaskV1 method signature updated to use new Connector type

The method now accepts components.Connector instead of the previous ConnectorEnum type, enhancing flexibility in connector handling while maintaining the same functionality.

9158-9382: ConnectorsTransfer method updated to use the new Connector type

The type migration from ConnectorEnum to Connector in this method completes the package-wide refactoring effort. This change improves API flexibility and type safety while maintaining the same functionality.

6558-9382:

❓ Verification inconclusive

Verify all implementations using these methods have been updated

This comprehensive type migration from ConnectorEnum to Connector across all connector-related methods should be accompanied by corresponding updates in calling code to ensure compatibility.

I recommend verifying that all code that calls these methods has been updated to use the new components.Connector type. You can use the following script to find any references to the old ConnectorEnum type that might need updating:

🏁 Script executed:

#!/bin/bash
# Search for any remaining references to ConnectorEnum that might need to be updated
echo "Searching for remaining references to ConnectorEnum..."
rg "ConnectorEnum" --type go

Length of output: 147

Verify the Connector type migration across all consumer code

It appears that no references to the old ConnectorEnum were found by the script. However, given the low-confidence output, please manually verify that all calling code using the connector-related methods (such as those in InstallConnector, UninstallConnector, etc.) have been updated to use the new components.Connector type.

  • Ensure no remaining references to ConnectorEnum exist in the codebase.
  • Confirm that all updated methods and their call sites have been migrated accordingly.
pkg/client/docs/models/operations/readconnectorconfigv1request.md (1)

6-9: Documentation correctly updated to reflect the type change.

The documentation has been properly updated to use the new components.Connector type instead of the previous ConnectorEnum. This change aligns with the broader refactoring effort to migrate from enumeration types to more general connector types across the codebase.

pkg/client/models/components/bankaccountrequest.go (2)

22-25: GetConnectorID method updated for consistency.

The return type has been correctly updated to match the field type change from string to *string, with appropriate handling of the nil case. This change maintains consistency between the field and its accessor method.

7-7:

❓ Verification inconclusive

ConnectorID field changed to optional.

The ConnectorID field has been changed from a required string to an optional pointer string. Make sure that all code using this field can handle the nil case appropriately.

Run the following script to check for places that might need updating to handle the nullable ConnectorID:

🏁 Script executed:

#!/bin/bash
# Find usages of BankAccountRequest.ConnectorID that might need updating
rg -A 2 -B 2 "\.ConnectorID\b" --type go

Length of output: 65749

Attention: Verify Nil Handling for ConnectorID Updates

The ConnectorID field in pkg/client/models/components/bankaccountrequest.go has been updated to be an optional pointer:

	ConnectorID   *string           `json:"connectorID,omitempty"`

This change means that downstream code must now correctly handle cases where ConnectorID is nil. A grep search across the codebase revealed many usages—in tests (e.g., in the API and tasks tests) and in various storage functions—that reference ConnectorID. Please ensure that:

  • Any comparisons or dereferences of ConnectorID are adequately guarded against nil.
  • The conversion or mapping logic between the client model (where ConnectorID is now a pointer) and internal models (which may expect a non-pointer value) correctly handles nil values.
  • All relevant tests (especially those performing equality checks on ConnectorID) are updated to account for the possibility of a nil value.

Kindly perform a manual verification of these aspects to ensure that nil cases are properly managed.

pkg/client/models/components/payment.go (2)

79-79: GetProvider method updated to return new Connector type.

The method signature has been properly updated to return *Connector instead of *ConnectorEnum, maintaining consistency with the field type change.

20-20:

✅ Verification successful

Provider field type changed from ConnectorEnum to Connector.

The Provider field has been updated to use the new Connector type instead of ConnectorEnum. This aligns with the broader refactoring effort in the PR to move away from enum types to more general string-based types.

While this change provides more flexibility, ensure that any code that relies on the specific values of the former enum still works correctly with the new string type.

Run the following script to check if there are any places where specific enum values were being used that might need updating:

🏁 Script executed:

#!/bin/bash
# Find usages of Provider that might need updating after the type change
rg -A 2 -B 2 "\.Provider\b" --type go

Length of output: 42635

Provider Field Update Verified: New Connector Type Usage Confirmed

The change in pkg/client/models/components/payment.go where the Provider field now uses the new Connector type—replacing the old ConnectorEnum—has been verified against the codebase. A search for usages of .Provider shows that:

  • Conversion functions (e.g., toV2Provider and ToV3Provider) are actively used to map the new string-based value back to the expected formats, ensuring that dependencies on the previous enum values are still served.
  • Test cases and migration scripts reference the Provider field consistently with the new type, indicating that functionality dependent on specific enum-like values is maintained through these helper functions.

Please verify that the conversion logic and any explicit comparisons in your domain-specific scenarios are thoroughly tested. Overall, the implementation appears correct and aligned with the refactoring objectives.

@paul-nicolas paul-nicolas merged commit 7932cd2 into main Apr 8, 2025
7 of 9 checks passed
@paul-nicolas paul-nicolas deleted the feat/tests-sdks branch April 8, 2025 14:24
paul-nicolas added a commit that referenced this pull request Apr 29, 2025
@paul-nicolas
feat: connectors sdks test e2e (#401)
d9ec2f3 
* feat: connectors sdks test e2e

* feat: account sdks tests e2e

* feat: bank accounts sdks tests e2e

* feat: payments sdks tests e2e

* feat: pi tests e2e with sdk

* feat: pools with sdk e2e tests
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@coderabbitai coderabbitai[bot] coderabbitai[bot] left review comments

@laouji laouji laouji approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@paul-nicolas @laouji
0