missing PassthroughBehavior enum in types in apigateway(v1)

[fgmarand]

Pre-Migration Checklist

• I've read the Migration Guide.
• I've checked AWS Forums and StackOverflow for similar migration issues.

Go Version Used

Go 1.23 (irrelevant).

Describe the Migration Issue

The constants apigatewayv2.PassthroughBehaviorWhenNoMatch, apigatewayv2.PassthroughBehaviorNever and apigatewayv2.PassthroughBehaviorWhenNoTemplates are missing from the v2 SDK.

As a consequence, the code in v2 uses plain magic constants in the source code instead of enum constants defined in the types package as happens for the other string constants.

Code Comparison

Client.PutIntegration method takes a PutIntegrationInput struct with a PassthroughBehavior field that is a *string in both v1 and v2, so no difference.

Observed Differences/Errors

One of the major changes in v2 is the use of the types package to store such enumerations and remove them as inline magic values, so one would expect these pre-existing constants to have been migrated, instead of just removed.

Additional Context

The likely cause is that the SDK is actually missing any use case for these constants, because there does not appear to be unit tests around their behaviour.

[RanVaknin]

Hi @fgmarand,

Are you referring to these enums?

In v2 the types are under github.com/aws/aws-sdk-go-v2/service/<service-name>/types

Thanks,
Ran~

[fgmarand]

Hi @RanVaknin Indeed. The file where they should live is https://github.com/aws/aws-sdk-go-v2/blob/main/service/apigateway/types/enums.go but they haven't been created there.

[RanVaknin]

Hi @fgmarand,

Hi @RanVaknin Indeed. The file where they should live is main/service/apigateway/types/enums.go but they haven't been created there.

These enums were only added to the APIGatewayV2 API, they were never a part of APIGW(v1) API.
https://github.com/aws/aws-sdk-go-v2/blob/main/service/apigatewayv2/types/enums.go

You need to use the correct import to be able to use the enums. If APIGW(v1) supports sending those values as a "magic constants", then it reflects an unmodeled service side behavior. Since the AWS SDKs are all code-generated from each Service's API model, the SDK team cannot introduce any new enums because those would require and upstream change on the model level. Since the missing enums is for the legacy API (APIGWv1) the service team is unlikely to modify it.

The solution here is to use APIGWv2 which has the modeled enums. (same exact behavior in Go SDK v1):

• Go SDK v1 apigateway missing enums

• Go SDK v1 apigatewayv2 having enums

• Go SDK v2 apigateway missing enums

• Go SDK v2 apigatewayv2 having enums

Thanks,
Ran~

[fgmarand]

The situation is indeed similar in V1 and V2, as you explained, so it is not entirely a matter of V1 to V2 migration, although it is to some extent:

• the V1 and V2 API Gateway functions uses these exact three same values: "WHEN_NO_MATCH", "NEVER", or "WHEN_NO_TEMPLATES", as documented on
  • GetIntegrationOutput.PassthroughBehavior
  • PutIntegrationInput.PassthroughBehavior
  • PutIntegrationOutput.PassthroughBehavior
  • UpdateIntegrationOutput.PassthroughBehavior
  • Integration.PassthroughBehavior
• the constants defined in V2 apigatewayv2.types
  • are the exact same three strings
  • are of type types.PassthroughBehavior, so cannot be used by API Gateway v1, as you mention, because those use a *string parameter
• to avoid discrepancy, in V1 the apigatewayv2.types constants could be used to provide the reference values because the types (string vs *string) and literal values matched, but the V2 constants are now a defined types PassthroughBehavior marking them as semantically specific.

But I guess the answer is "Won't fix" anyway ?

[RanVaknin]

Hi @fgmarand ,

I'm really confused by your answer. For all intents and purposes lets only talk about the Go SDK v2 not v1. This issue was opened as a migration issue and I don't think it was classified correctly and that adds to my confusion.

The Go SDK has 2 apigateway API clients:

apigateway (v1) and apigatewayv2 (v2). The backend API service of both versions might have backend support for sending "WHEN_NO_MATCH" or any of the other PassthroughBehavior enums as a literal strings, but in the apigateway model itself, did not model those enums therefore the SDK will not have those enums.

Since the SDK is generated from the model files of each API, and those are updated and maintained by the upstream service team, the SDK team cannot modify/ add / remove enums from the SDK.

Since the SDK is generated from the model files maintained by the upstream service team, the SDK team cannot modify, add, or remove enums. The issue primarily concerns apigateway, a legacy API likely retained to support existing customers. Given that apigatewayv2 offers the needed functionality and considering that the legacy version is in maintenance mode, it is unlikely that the APIGW service team will prioritize changes to it.

But I guess the answer is "Won't fix" anyway ?

It's not about unwillingness to fix; rather, changes to the SDK aren't actionable by our team because they require updates to the model files by the backend service team. These types of requests would typically be routed internally, but realistically, they are not likely to be prioritized due to the legacy nature of the API and the availability of workarounds using string values.

Is there anything stopping you from using apigatewayv2?

Thanks,
Ran~

[fgmarand]

"Is there anything stopping you from using apigatewayv2" : existing code. I could convert it, I guess, except v2 only supports WebSocket and "HTTP" APIs, and this is a "RestApi", that was specifically chosen against "HTTP" APIs by stakeholders to use the extended feature set missing from "HTTP" APIs as outlined on https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-vs-rest.html and more specifically: API Keys, Per-client usage limiting, and Per-client usage throttling.

[github-actions]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.

[fgmarand]

Seems I had closed the issue too early: this has to be a "REST" API as outlined above, due to the missing features in v2 "HTTP" APIs.

[lucix-aws]

We're getting off-topic here. I believe we've established that nothing is actually missing in the Go SDK itself - that is to say, all of the content in the API models for apigatewayv1 and v2 are fully present their Go v2 SDK service clients. Therefore, there is no concrete SDK defect that is actionable for us. Closing accordingly.

[github-actions]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.