cloudfoundry / cf-java-client

Java Client Library for Cloud Foundry
Apache License 2.0
328 stars 318 forks source link

The client can't parse SpaceSupporter role #1132

Closed theghost5800 closed 2 years ago

theghost5800 commented 2 years ago

When used user token has SpaceSupporter role in target CF space, then the client fails with the following error[1]. I am using cf-java-client 4.16.0. The issue is located at client/v3/roles/RoleType.java and related with converting String to Enum. I have read here that SpaceSupporter role is still in beta and it can be modified in future but at least I expect cf-java-client to be still functional when CF role is not known for the client.

[1]

org.cloudfoundry.reactor.util.JsonParsingException: Cannot construct instance of `org.cloudfoundry.client.v3.roles.RoleType`, problem: Unknown role type: space_supporter
 at [Source: (byte[])"{
  "pagination":{
    "total_results":3,
    "total_pages":1
    },
    "last":{
   "[truncated 2837 bytes]; line: 83, column: 14] (through reference chain: org.cloudfoundry.client.v3.roles.ListRolesResponse$Json["resources"]->java.util.ArrayList[2]->org.cloudfoundry.client.v3.roles.RoleResource$Json["type"])
    at org.cloudfoundry.reactor.util.JsonCodec.lambda$decode$0(JsonCodec.java:46)
    Suppressed: reactor.core.publisher.FluxOnAssembly$OnAssemblyException: 
Assembly trace from producer [reactor.core.publisher.MonoFlatMap] :
    reactor.core.publisher.Mono.checkpoint(Mono.java:1879)
    org.cloudfoundry.reactor.client.v3.roles.ReactorRolesV3.list(ReactorRolesV3.java:72)
Error has been observed at the following site(s):
    |_ Mono.checkpoint ⇢ at org.cloudfoundry.reactor.client.v3.roles.ReactorRolesV3.list(ReactorRolesV3.java:72)
dmikusa commented 2 years ago

I'm not opposed to adding support for this. If the name of the role does change down the road, we'd be in no worse of a spot than we are now, failures to parse.

Is this something you'd like to submit a PR to add? Happy to review/merge if that's the case. Otherwise, we can add this to the backlog.

I expect cf-java-client to be still functional when CF role is not known for the client

I don't particularly agree here. If a mistyped role is given, it's helpful to have the client be able to detect that. This particular case is a little weird because that "mistyped role" is coming from the server and it's not exactly an error, it's new functionality, but its new functionality that is not supported in the client so to me, an error is again expected.

I don't know how we could handle this short of making a "UNKNOWN_ROLE" entry on the enum and I don't really like that idea. It would be more convenient for this particular case, but in other cases, I think it would require users of the client to check for UNKNOWN_ROLE in a non-elegant way. It also opens up the case that a user could submit a request to the server with a role of type UKNOWN_ROLE that is completely fictitious, sure that's the user's fault, but by not having this type we can eliminate that problem at compile time.

If you have any ideas on how we could handle this case where a new type is created on the server, I'm open to hearing your thoughts.

theghost5800 commented 2 years ago

I have find out that this issue can be mitigated by setting roletypes which are supported by the client itself as query parameter. So this issue can be handled from consumers of cf-java-client and retrieve only supported roles.