Enums have duplicate entries in BalancePlatformService-v1.json about adyen-openapi HOT 15 CLOSED

Also the values don't seem to match the ones described in https://docs.adyen.com/api-explorer/#/balanceplatform/latest/overview

from adyen-openapi.

Hi @andrei-ivanov,

This is currently done to support migration of these values from PascalCase to camelCase. In the future versions of the API we will leave only camelCase values.

However, this shouldn't cause any problems with the tooling, because, as far as we know, this format is correct from the OpenAPI and JSON Schema points of view (here https://json-schema.org/draft/2020-12/json-schema-validation.html#rfc.section.6.1.2 it says that values should be unique, and these values ARE unique as they are case sensitive).

What is the OpenAPI Java generator that you are using? Maybe we can raise this issue there?

from adyen-openapi.

Also the values don't seem to match the ones described in https://docs.adyen.com/api-explorer/#/balanceplatform/latest/overview

We've updated the specs today, they should match now. If you still see any discrepancies, please let us know the exact values that are not matching, so we can look more into this.

from adyen-openapi.

Hi,
The generator that I've tried is the java one and in Java the enums look like this:

public enum StatusEnum {
    ACTIVE("Active"),
    
    CLOSED("Closed"),
    
    INACTIVE("Inactive"),
    
    LOST("Lost"),
    
    REQUESTED("Requested"),
    
    STOLEN("Stolen"),
    
    SUSPENDED("Suspended");

    private String value;

    StatusEnum(String value) {
      this.value = value;
    }

    @JsonValue
    public String getValue() {
      return value;
    }

    @Override
    public String toString() {
      return String.valueOf(value);
    }

    @JsonCreator
    public static StatusEnum fromValue(String value) {
      for (StatusEnum b : StatusEnum.values()) {
        if (b.value.equals(value)) {
          return b;
        }
      }
      throw new IllegalArgumentException("Unexpected value '" + value + "'");
    }
}

So while the same value could be written with multiple cases (lower/upper), the generated enum entry is the same.

from adyen-openapi.

@andrei-ivanov thank you. We are looking into this issue to see how we can improve our OpenAPI generator to avoid value duplication, even if they are in different case.

from adyen-openapi.

Any conclusion on this issue?

from adyen-openapi.

Btw, isn't this a new API?
How come it has legacy values for enums and why does it has to handle them if it's a new API?

from adyen-openapi.

@andrei-ivanov yes, it's a bug in our OpenAPI generator, we are looking into the fix.

The reason is that internally it's the same enum for both versions - old and new.

We will publish an update soon.

from adyen-openapi.

@andrei-ivanov I've pushed the fix, could you please verify that everything is correct now?

from adyen-openapi.

It works now, but I was under the impression that the enums should use camelCase now 🙂
But then I noticed that the services actually still use the PascalCase values.

from adyen-openapi.

For example, when creating a test payment instrument, the returned value has a status of inactive, and that doesn't match the value in the spec.

JSON decoding error: Cannot construct instance of com.adyen.balanceplatform.model.PaymentInstrument$StatusEnum, problem: Unexpected value 'inactive'

Same for active, after activating a card.

JSON decoding error: Cannot construct instance of com.adyen.balanceplatform.model.PaymentInstrument$StatusEnum, problem: Unexpected value 'active'

So it seems the services really use camelCase and the spec should match, otherwise the generated code will not work.

from adyen-openapi.

@andrei-ivanov are you using v1 or v2 of the API?

from adyen-openapi.

v2, as recommended 😁

from adyen-openapi.

Testing now with v1, indeed, I shouldn't have mixed them

from adyen-openapi.

Ok, with v1, the only flow I have, create card and then activate card, works with these values 🙂

Thanks.

from adyen-openapi.