Fix api_gateway_authorizer caching ttl in case explicitly set to 0

[f3lang]

Community Note

• Please vote on this pull request by adding a 👍 reaction to the original pull request comment to help the community and maintainers prioritize this request
• Please do not leave "+1" comments, they generate extra noise for pull request followers and do not help prioritize the request

Fixes #705

Changes proposed in this pull request:

The GetOk will compare the value to the default zero value of a type. When the ttl is set to 0, the value matches the default zero value of the type Integer and will be ignored for the api request.

Normally not a problem, but in this case, this results in an authorizer with a cache ttl of null, which defaults to 300s on AWS side. This is also not visible properly in the AWS console, since the value is displayed as "undefined" and the checkbox for caching is not activated. So it looks like the caching is disabled, but the default caching ttl of 300s kicks in and produces unreliable results in the API Gateway behaviour.

So this change uses the GetOkExists function for the parameter validation which will not compare
the value to the type zero value and therefore the resource will now accept an explicitly value of 0 for
the parameter authorizer_result_ttl_in_seconds.

[f3lang]

Hi, is there anything missing, which i should add to this pr?

[f3lang]

I'll just try @bflad
I hope you are the right guy for this pr :) Can you have a look at it?

[f3lang]

Hi, any updates on this?

[bflad]

Hi @f3lang 👋 Thank you for submitting this and sorry for the delays in getting it reviewed. In practice we have found that d.GetOkExists() only works in certain scenarios, so unfortunately it is not a preferable solution we would be looking for here.

Since the API denotes a default of 300, but omits it from the API response if its unset, a solution like the one recently submitted in #9605 may cover the problem better here, but it needs to be verified, especially with existing configurations.

Would you be able to take a look at #9605 and see if it seems like a reasonable fix? Thanks.

[bflad]

Closing due to lack of response -- please see #8267 (comment) for additional information and further tracking of fixing this issue.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!