Get exception from get_aws_region when call it in GitHub Actions

[os-esh]

Hi there. I encounter a problem when I use aws_get_region in GitHub actions with Miscrosoft servers

Here is the function call: config = AWSConfig(;creds=auth_params, region=@mock(aws_get_region(default=DEFAULT_REGION)))

So I'm expecting to get DEFAULT_REGION because I don't have any ENV vars for region in GitHub actions and it's running on a Microsoft server.

But instead, before returning default region aws_get_region function calls IMDS and I get this error:

#15 65.85 ┌ Error: 2023-09-06 12:05:55: HTTP.Exceptions.StatusError(400, "PUT", "/latest/api/token", HTTP.Messages.Response:
#15 65.85 │ """
#15 65.85 │ HTTP/1.1 400 Bad Request
#15 65.85 │ Content-Type: text/xml; charset=utf-8
#15 65.85 │ Server: Microsoft-IIS/10.0
#15 65.85 │ Date: Wed, 06 Sep 2023 12:05:53 GMT
#15 65.85 │ Content-Length: 322
#15 65.85 │ 
#15 65.85 │ <?xml version="1.0" encoding="utf-8"?>
#15 65.85 │ <Error xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
#15 65.85 │     <Code>InvalidHttpVerb</Code>
#15 65.85 │     <Message>The HTTP verb specified was not recognized by the server.</Message>
#15 65.85 │     <Details>'PUT' is not a supported verb.</Details>
#15 65.85 │ </Error>""")

With this stacktrace:

refresh_token!(session::AWS.IMDS.Session, duration::Int16) at IMDS.jl:94
refresh_token! at IMDS.jl:53 [inlined]
request(session::AWS.IMDS.Session, method::String, path::String; kwargs::Base.Pairs{Symbol, Union{}, Tuple{}, NamedTuple{(), Tuple{}}}) at IMDS.jl:104
request at IMDS.jl:100 [inlined]
get(session::AWS.IMDS.Session, path::String) at IMDS.jl:168
region at IMDS.jl:191 [inlined]
region at IMDS.jl:192 [inlined]
macro expansion at mock.jl:29 [inlined]
aws_get_region(; profile::Nothing, config::Nothing, default::String) at AWSCredentials.jl:139
aws_get_region at AWSCredentials.jl:655 [inlined]

I see several problems here, for your consideration:

1. I have fresh credentials, so I don't know why it's trying to refresh them.
2. Maybe IMDS shouldn't rethrow HTTP and should process them.
3. Maybe aws_get_region should be wrapped in try-catch to return a default value on error.

[ericphanson]

I am seeing the exact same HTTP 400 error coming from refresh_token!, although my entrypoint was different:

    [1] refresh_token!(session::AWS.IMDS.Session, duration::Int16)
      @ AWS.IMDS ~/.julia/packages/AWS/SchLh/src/IMDS.jl:94
    [2] refresh_token!
      @ ~/.julia/packages/AWS/SchLh/src/IMDS.jl:53 [inlined]
    [3] request(session::AWS.IMDS.Session, method::String, path::String; kwargs::Base.Pairs{Symbol, Union{}, Tuple{}, NamedTuple{(), Tuple{}}})
      @ AWS.IMDS ~/.julia/packages/AWS/SchLh/src/IMDS.jl:104
    [4] request
      @ ~/.julia/packages/AWS/SchLh/src/IMDS.jl:100 [inlined]
    [5] get(session::AWS.IMDS.Session, path::String)
      @ AWS.IMDS ~/.julia/packages/AWS/SchLh/src/IMDS.jl:168
    [6] get
      @ ~/.julia/packages/AWS/SchLh/src/IMDS.jl:180 [inlined]
    [7] ec2_instance_credentials(profile::String)
      @ AWS ~/.julia/packages/AWS/SchLh/src/AWSCredentials.jl:233
    [8] (::AWS.var"#12#18"{String})()
      @ AWS ~/.julia/packages/AWS/SchLh/src/AWSCredentials.jl:132
    [9] AWS.AWSCredentials(; profile::Nothing, throw_cred_error::Bool)
      @ AWS ~/.julia/packages/AWS/SchLh/src/AWSCredentials.jl:138
   [10] AWS.AWSConfig()
      @ AWS ~/.julia/packages/AWS/SchLh/src/AWSConfig.jl:32
   [11] #global_aws_config#91
      @ ~/.julia/packages/AWS/SchLh/src/AWS.jl:81 [inlined]
   [12] global_aws_config
      @ ~/.julia/packages/AWS/SchLh/src/AWS.jl:79 [inlined]

[ericphanson]

I notice refresh_token! was recently modified by #655 (cc @omus) although the diff there doesn't look like it is introducing a new PUT request

[ericphanson]

Aha. It turns out I had commented out this block in my github actions workflow:

      - uses: aws-actions/configure-aws-credentials@v2
        with:
          aws-region: us-east-2
          role-to-assume: arn:aws:iam::[...redacted...]
          role-duration-seconds: 43200

Once I added that back, I got expected behavior.

So I think there is something wrong where misconfigured s3 role/access gives a very weird/confusing error here.