Code generation: update services and models #1492

AdyenAutomationBot · 2025-05-21T11:38:31Z

OpenAPI spec files or templates have been modified on 21-05-2025 by commit.

Features 💎

BalancePlatform API
- Add walletProviderDeviceType in TransactionRuleRestrictions
- Add enum INTEREST in TransferRoute.CategoryEnum
Transfer API
- Add attribute executionDate in Transfer, TransferData and TransferInfo
BalancePlatform Webhooks
- Add new webhook events balancePlatform.networkToken.created and balancePlatform.networkToken.updated to be notified upon creation and update of Network Tokens
Transfer Webhooks
- Add attribute executionDate in TransferData

gemini-code-assist

Hello @AdyenAutomationBot, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

Summary of Changes

Hello team,

Gemini or gemini-code-assist here to provide a summary of this pull request. This PR updates the generated Java code based on recent modifications to the OpenAPI specification, as indicated by the title and description. The primary functional change involves the introduction of a new ExecutionDate model and its integration into the Transfer and TransferData models within both the main Transfers API and the Transfer Webhooks package. Additionally, some minor documentation improvements were made to existing models in the ACS webhooks package.

Highlights

New Model: ExecutionDate: A new model class, ExecutionDate, has been added to represent the date and timezone for scheduled transfers.
Transfers API Updates: The Transfer and TransferData models in the main Transfers API now include the new executionDate field, allowing for specifying the processing date and timezone for transfers.
Transfer Webhooks Updates: The TransferData model in the Transfer Webhooks package has been updated to include the executionDate field, and a corresponding ExecutionDate model was added to this package.
Documentation Improvements: Minor Javadoc comments were updated in the AuthenticationNotificationData and PurchaseInfo models within the ACS webhooks package for improved clarity.

Changelog

Click here to see the changelog

src/main/java/com/adyen/model/acswebhooks/AuthenticationNotificationData.java
- Updated Javadoc comments for the id field (lines 166, 177, 187).
- Updated Javadoc comments for the paymentInstrumentId field (lines 198, 209, 219).
src/main/java/com/adyen/model/acswebhooks/PurchaseInfo.java
- Updated Javadoc comments for the date field (lines 52, 63, 73).
- Updated Javadoc comments for the merchantName field (lines 84, 95, 105).
src/main/java/com/adyen/model/transfers/ExecutionDate.java
- Added a new model class ExecutionDate with date (LocalDate) and timezone (String) properties.
src/main/java/com/adyen/model/transfers/Transfer.java
- Added import for ExecutionDate (line 21).
- Added JSON_PROPERTY_EXECUTION_DATE constant (line 171).
- Added executionDate field of type ExecutionDate (line 172).
- Added getter, setter, and chaining methods for executionDate (lines 873-901).
- Updated equals, hashCode, and toString methods to include executionDate (lines 1182, 1195, 1212).
src/main/java/com/adyen/model/transfers/TransferData.java
- Added import for ExecutionDate (line 21).
- Added JSON_PROPERTY_EXECUTION_DATE constant (line 198).
- Added executionDate field of type ExecutionDate (line 199).
- Added getter, setter, and chaining methods for executionDate (lines 1056-1084).
- Updated equals, hashCode, and toString methods to include executionDate (lines 1497, 1514, 1535).
src/main/java/com/adyen/model/transferwebhooks/ExecutionDate.java
- Added a new model class ExecutionDate with date (LocalDate) and timezone (String) properties for the transfer webhooks package.
src/main/java/com/adyen/model/transferwebhooks/TransferData.java
- Added import for ExecutionDate (line 21).
- Added JSON_PROPERTY_EXECUTION_DATE constant (line 198).
- Added executionDate field of type ExecutionDate (line 199).
- Added getter, setter, and chaining methods for executionDate (lines 1056-1084).
- Updated equals, hashCode, and toString methods to include executionDate (lines 1497, 1514, 1535).

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	`/gemini review`	Performs a code review for the current pull request in its current state.
Pull Request Summary	`/gemini summary`	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	`/gemini help`	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Code generated anew,
From spec changes, fresh and true.
Models updated fast,
Future API built to last.

Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

gemini-code-assist

Code Review

This pull request updates services and models, likely based on modifications to OpenAPI specifications or templates. The main change involves the introduction of an ExecutionDate model and its integration into various transfer-related classes. The generated code appears consistent with these changes. My primary feedback concerns a potential maintainability issue due to model duplication.

Summary of Findings

Code Duplication of ExecutionDate Model: The ExecutionDate model class is duplicated in two packages: com.adyen.model.transfers and com.adyen.model.transferwebhooks. A review comment with medium severity has been added to address this potential maintainability issue.
Javadoc Improvements (Low Severity - Not Commented): Javadoc comments in src/main/java/com/adyen/model/acswebhooks/AuthenticationNotificationData.java and src/main/java/com/adyen/model/acswebhooks/PurchaseInfo.java were updated. These changes generally improve clarity (e.g., adding 'The' to start sentences, and providing a more descriptive explanation for merchantName in PurchaseInfo.java). These are positive but considered low-severity changes, so no specific comments were added due to review settings.
Minimal Javadoc for Generated Methods (Low Severity - Not Commented): The newly generated getters, setters, and builder-style methods for the executionDate field in Transfer.java, TransferData.java (both versions), and TransferInfo.java have minimal Javadoc (e.g., @param executionDate without further description of the parameter's role in that context). While typical for auto-generated code, more descriptive Javadoc could be beneficial if manual enhancements were part of the development workflow. This is considered a low-severity observation, so no specific comments were added due to review settings.

Merge Readiness

The changes in this PR are largely related to code generation. The most significant point to consider is the duplication of the ExecutionDate model across different packages, which has been flagged as a medium severity maintainability concern. It would be beneficial to discuss or address this to ensure long-term code health. Other changes, such as Javadoc updates and the integration of the new executionDate field into existing models, appear to be standard and correctly implemented as per the generation logic.

I am unable to approve pull requests. It is recommended that the model duplication issue be reviewed and a decision made on how to proceed before merging. Other reviewers should make the final determination on merging.

gemini-code-assist · 2025-05-21T11:41:15Z

src/main/java/com/adyen/model/transferwebhooks/ExecutionDate.java

+   */
+  @JsonProperty(JSON_PROPERTY_DATE)
+  @JsonInclude(value = JsonInclude.Include.USE_DEFAULTS)
+  public void setDate(LocalDate date) {
+    this.date = date;
+  }
+
+  /**
+   * The timezone that applies to the execution date. Use a timezone identifier from the [tz database](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).  Example: **America/Los_Angeles**.  Default value: **Europe/Amsterdam**.
+   *
+   * @param timezone The timezone that applies to the execution date. Use a timezone identifier from the [tz database](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).  Example: **America/Los_Angeles**.  Default value: **Europe/Amsterdam**.
+   * @return the current {@code ExecutionDate} instance, allowing for method chaining
+   */
+  public ExecutionDate timezone(String timezone) {
+    this.timezone = timezone;
+    return this;
+  }
+
+  /**
+   * The timezone that applies to the execution date. Use a timezone identifier from the [tz database](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).  Example: **America/Los_Angeles**.  Default value: **Europe/Amsterdam**.
+   * @return timezone The timezone that applies to the execution date. Use a timezone identifier from the [tz database](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).  Example: **America/Los_Angeles**.  Default value: **Europe/Amsterdam**.
+   */
+  @JsonProperty(JSON_PROPERTY_TIMEZONE)
+  @JsonInclude(value = JsonInclude.Include.USE_DEFAULTS)
+  public String getTimezone() {
+    return timezone;
+  }
+
+  /**
+   * The timezone that applies to the execution date. Use a timezone identifier from the [tz database](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).  Example: **America/Los_Angeles**.  Default value: **Europe/Amsterdam**.
+   *
+   * @param timezone The timezone that applies to the execution date. Use a timezone identifier from the [tz database](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).  Example: **America/Los_Angeles**.  Default value: **Europe/Amsterdam**.
+   */
+  @JsonProperty(JSON_PROPERTY_TIMEZONE)
+  @JsonInclude(value = JsonInclude.Include.USE_DEFAULTS)
+  public void setTimezone(String timezone) {
+    this.timezone = timezone;
+  }
+
+  /**
+   * Return true if this ExecutionDate object is equal to o.
+   */
+  @Override
+  public boolean equals(Object o) {
+    if (this == o) {
+      return true;
+    }
+    if (o == null || getClass() != o.getClass()) {
+      return false;
+    }
+    ExecutionDate executionDate = (ExecutionDate) o;
+    return Objects.equals(this.date, executionDate.date) &&
+        Objects.equals(this.timezone, executionDate.timezone);
+  }
+
+  @Override
+  public int hashCode() {
+    return Objects.hash(date, timezone);
+  }
+
+  @Override
+  public String toString() {
+    StringBuilder sb = new StringBuilder();
+    sb.append("class ExecutionDate {\n");
+    sb.append("    date: ").append(toIndentedString(date)).append("\n");
+    sb.append("    timezone: ").append(toIndentedString(timezone)).append("\n");
+    sb.append("}");
+    return sb.toString();
+  }
+
+  /**
+   * Convert the given object to string with each line indented by 4 spaces
+   * (except the first line).
+   */
+  private String toIndentedString(Object o) {
+    if (o == null) {
+      return "null";
+    }
+    return o.toString().replace("\n", "\n    ");
+  }
+
+/**
+   * Create an instance of ExecutionDate given an JSON string
+   *
+   * @param jsonString JSON string
+   * @return An instance of ExecutionDate
+   * @throws JsonProcessingException if the JSON string is invalid with respect to ExecutionDate
+   */
+  public static ExecutionDate fromJson(String jsonString) throws JsonProcessingException {
+    return JSON.getMapper().readValue(jsonString, ExecutionDate.class);
+  }
+/**
+  * Convert an instance of ExecutionDate to an JSON string
+  *
+  * @return JSON string
+  */
+  public String toJson() throws JsonProcessingException {
+    return JSON.getMapper().writeValueAsString(this);
+  }
+}


This new ExecutionDate class (in package com.adyen.model.transferwebhooks) appears to be identical in structure and purpose to com.adyen.model.transfers.ExecutionDate (located in src/main/java/com/adyen/model/transfers/ExecutionDate.java), which is also part of this pull request's changes.

While this might be an artifact of the OpenAPI generation process from separate specifications (as suggested by the PR title/description), having duplicated model classes can introduce maintainability challenges in the long run:

Inconsistency Risk: If one class requires an update (e.g., a new field, modified validation rules, or Javadoc improvements), the other instance might be overlooked. This could lead to divergent behavior or understanding of ExecutionDate in different parts of the system.

Increased Maintenance Overhead: Any changes to the concept of an ExecutionDate would need to be applied and tested in multiple places.

Code Bloat: It adds redundant code to the codebase.

Could we investigate if it's feasible to define ExecutionDate in a shared common module or adjust the OpenAPI specifications/generation templates to reference a single, canonical definition? If this duplication is a known and accepted outcome of the current generation strategy due to specific constraints, it would be beneficial to acknowledge this, perhaps with a comment in the code or internal documentation explaining the rationale.

AdyenAutomationBot force-pushed the sdk-automation/models branch from a88239a to fdd9125 Compare May 21, 2025 11:38

AdyenAutomationBot requested a review from a team as a code owner May 21, 2025 11:38

gemini-code-assist bot reviewed May 21, 2025

View reviewed changes

gemini-code-assist bot suggested changes May 21, 2025

View reviewed changes

false[adyen-sdk-automation] automated change

f56348d

AdyenAutomationBot force-pushed the sdk-automation/models branch from fdd9125 to f56348d Compare May 21, 2025 11:54

Add unit tests for new events

c7c92be

gcatanese added the Feature Indicates a new feature addition label May 22, 2025

gcatanese approved these changes May 22, 2025

View reviewed changes

gcatanese merged commit 1efbaa9 into main May 22, 2025
4 checks passed

AdyenAutomationBot mentioned this pull request May 20, 2025

Release v38.1.0 #1489

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Code generation: update services and models #1492

Code generation: update services and models #1492

Uh oh!

AdyenAutomationBot commented May 21, 2025 •

edited by gcatanese

Loading

Uh oh!

gemini-code-assist bot left a comment

Uh oh!

gemini-code-assist bot left a comment

Uh oh!

gemini-code-assist bot May 21, 2025

Uh oh!

Uh oh!

Uh oh!

Code generation: update services and models #1492

Code generation: update services and models #1492

Uh oh!

Conversation

AdyenAutomationBot commented May 21, 2025 • edited by gcatanese Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Features 💎

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Summary of Changes

Highlights

Changelog

Footnotes

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Summary of Findings

Merge Readiness

Uh oh!

gemini-code-assist bot May 21, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

AdyenAutomationBot commented May 21, 2025 •

edited by gcatanese

Loading