Aws-sdk-rust - AWS SDK for the Rust Programming Language

Related tags

Utilities rust aws
Overview

The AWS SDK for Rust Docs MSRV Usage Guide

This repo contains the new AWS SDK for Rust (the SDK) and its public roadmap.

Please Note: The SDK is currently released as a developer preview and is intended strictly for feedback purposes only. Do not use this SDK for production workloads.

The SDK is code generated from Smithy models that represent each AWS service. The code used to generate the SDK can be found in smithy-rs.

Getting Started with the SDK

Examples are availble for many services and operations, check out the examples folder.

For a step-by-step guide including several advanced use cases, check out the Developer Guide.

The SDK provides one crate per AWS service. You must add Tokio as a dependency within your Rust project to execute asynchronous code.

  1. Create a new Rust project: cargo new sdk-example

  2. Add dependencies to DynamoDB and Tokio to your Cargo.toml file:

    [dependencies]
    aws-config = "0.3.0"
    aws-sdk-dynamodb = "0.3.0"
    tokio = { version = "1", features = ["full"] }
  3. Provide your AWS credentials with the default credential provider chain, which currently looks in:

    • Environment variables: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_REGION
    • Web Identity Token credentials from the environment or container (including EKS)
    • The default credentials files located in ~/.aws/config and ~/.aws/credentials (location can vary per platform)
    • ECS Container Credentials (IAM roles for tasks)
    • EC2 Instance Metadata Service (IAM Roles attached to instance) Note: SSO is not supported yet.
  4. Make a request using DynamoDB

use aws_sdk_dynamodb::{Client, Error};

#[tokio::main]
async fn main() -> Result<(), Error> {
    let shared_config = aws_config::load_from_env().await;
    let client = Client::new(&shared_config);
    let req = client.list_tables().limit(10);
    let resp = req.send().await?;
    println!("Current DynamoDB tables: {:?}", resp.table_names);
    Ok(())
}

Prerequisites

In order to use the SDK, you must already have Rust and Cargo installed. If you don't, these instructions describe how to install Rust and Cargo.

Using the SDK

While we're working on the SDK, detailed usage instructions will be added to the Developer Guide. Please suggest additional sections for the guide by opening an issue and describing what you are trying to do.

Getting Help

Feedback and Contributing

Feedback

The SDK uses GitHub Issues to track feature requests and issues with the SDK. In addition, we use GitHub Projects to provide users with a high level view of our roadmap and the features we're actively working on.

You can provide feedback or report a bug by submitting a GitHub issue. This is the preferred mechanism to give feedback so that other users can engage in the conversation, +1 issues, etc. Issues you open will be evaluated for our roadmap in the Developer Preview launch.

Contributing

If you are interested in contributing to the SDK, please take a look at CONTRIBUTING

Supported Rust Versions (MSRV)

The SDK currently requires a minimum of Rust 1.54, and is not guaranteed to build on compiler versions earlier than that. While we are still in alpha, we will be keeping the minimum compiler version two releases behind the latest stable release where possible (so if the latest stable were 1.55, we would be on 1.53). However, we are not making any guarantees around this at present. Increases in minimum required Rust version will be called out in the Release Notes for new releases of the SDK.

Additional Resources

Security

See CONTRIBUTING for more information.

License

This project is licensed under the Apache-2.0 License.

Comments
  • Tuning AWS Rust SDK HTTP request settings for latency-aware Amazon DynamoDB applications

    Tuning AWS Rust SDK HTTP request settings for latency-aware Amazon DynamoDB applications

    Describe the bug

    As per discussion: https://github.com/awslabs/aws-sdk-rust/discussions/557

    The DynamoDB SDK does not retry based on the with_max_attempts, but its exits at the first failure.

    The workaround is to put the queries inside a custom code:

    let mut retry_count = 1;
    while retry_count < 5 {
         let result = RunQuery().await;
         if let Ok(output) = result {
                    //do something or break
          } else {
              retry_count += 1;
          }
    }
    

    Expected Behavior

    If I set a timeout at 30ms and 5 retries, for example

    I expect the Lambda Duration to be between > 30ms and 150ms based on retries and not exiting immediately.

    Current Behavior

    The SDK does not retry at all. I think it is for all the clients and not just DynamoDB

    Reproduction Steps

    set the following configuration:

    let timeout_config = timeout::Config::new()
            .with_api_timeouts(
                timeout::Api::new()
                    // This timeout acts at the "Request to a service" level. When the SDK makes a request to a
                    // service, that "request" can contain several HTTP requests. This way, you can retry
                    // failures that are likely spurious, or refresh credentials.
                    .with_call_timeout(TriState::Set(Duration::from_millis(30)))
                    // This timeout acts at the "HTTP request" level and sets a separate timeout for each
                    // HTTP request made as part of a "service request."
                    .with_call_attempt_timeout(TriState::Set(Duration::from_millis(30))),
            )
            .with_http_timeouts(
                timeout::Http::new()
                    // A limit on the amount of time an application takes to attempt to read the first byte over
                    // an established, open connection after a write request.
                    // Also known as the "time to first byte" timeout.
                    .with_read_timeout(TriState::Set(Duration::from_millis(10)))
                    // A time limit for completing the connect-handshake. The time starts when
                    // making an initial connect attempt on a socket.
                    .with_connect_timeout(TriState::Set(Duration::from_millis(10))),
            );
        let config = aws_config::from_env()
            .retry_config(RetryConfig::new().with_max_attempts(10))
            .timeout_config(timeout_config)
            .load()
            .await;
    
        let dynamodb_client = aws_sdk_dynamodb::Client::new(&config);
    

    you will get this message: request has timed out: API call (single attempt) timeout occurred after 30ms.

    But you will notice that the Lambda Duration is 32ms, so the SDK did not retry.

    Possible Solution

    Implement retries with exponential backoff like the other AWS-SDK

    Additional Information/Context

    Libs:

    aws-sdk-dynamodb = "0.13.0"
    lambda_http = "0.5.0"
    lambda_runtime = "0.5.1"
    rustc 1.61.0 
    

    Version

    cargo tree | grep aws- ├── aws-config v0.13.0 │   ├── aws-http v0.13.0 │   │   ├── aws-smithy-http v0.43.0 │   │   │   ├── aws-smithy-types v0.43.0 │   │   ├── aws-smithy-types v0.43.0 (*) │   │   ├── aws-types v0.13.0 │   │   │   ├── aws-smithy-async v0.43.0 │   │   │   ├── aws-smithy-client v0.43.0 │   │   │   │   ├── aws-smithy-async v0.43.0 (*) │   │   │   │   ├── aws-smithy-http v0.43.0 (*) │   │   │   │   ├── aws-smithy-http-tower v0.43.0 │   │   │   │   │   ├── aws-smithy-http v0.43.0 (*) │   │   │   │   ├── aws-smithy-protocol-test v0.43.0 │   │   │   │   ├── aws-smithy-types v0.43.0 (*) │   │   │   ├── aws-smithy-http v0.43.0 (*) │   │   │   ├── aws-smithy-types v0.43.0 (*) │   ├── aws-sdk-sso v0.13.0 │   │   ├── aws-endpoint v0.13.0 │   │   │   ├── aws-smithy-http v0.43.0 (*) │   │   │   ├── aws-types v0.13.0 (*) │   │   ├── aws-http v0.13.0 (*) │   │   ├── aws-sig-auth v0.13.0 │   │   │   ├── aws-sigv4 v0.13.0 │   │   │   │   ├── aws-smithy-http v0.43.0 (*) │   │   │   ├── aws-smithy-http v0.43.0 (*) │   │   │   ├── aws-types v0.13.0 (*) │   │   ├── aws-smithy-async v0.43.0 (*) │   │   ├── aws-smithy-client v0.43.0 (*) │   │   ├── aws-smithy-http v0.43.0 (*) │   │   ├── aws-smithy-http-tower v0.43.0 (*) │   │   ├── aws-smithy-json v0.43.0 │   │   │   └── aws-smithy-types v0.43.0 (*) │   │   ├── aws-smithy-types v0.43.0 (*) │   │   ├── aws-types v0.13.0 (*) │   ├── aws-sdk-sts v0.13.0 │   │   ├── aws-endpoint v0.13.0 (*) │   │   ├── aws-http v0.13.0 (*) │   │   ├── aws-sig-auth v0.13.0 (*) │   │   ├── aws-smithy-async v0.43.0 (*) │   │   ├── aws-smithy-client v0.43.0 (*) │   │   ├── aws-smithy-http v0.43.0 (*) │   │   ├── aws-smithy-http-tower v0.43.0 (*) │   │   ├── aws-smithy-query v0.43.0 │   │   │   ├── aws-smithy-types v0.43.0 (*) │   │   ├── aws-smithy-types v0.43.0 (*) │   │   ├── aws-smithy-xml v0.43.0 │   │   ├── aws-types v0.13.0 (*) │   ├── aws-smithy-async v0.43.0 (*) │   ├── aws-smithy-client v0.43.0 (*) │   ├── aws-smithy-http v0.43.0 (*) │   ├── aws-smithy-http-tower v0.43.0 (*) │   ├── aws-smithy-json v0.43.0 (*) │   ├── aws-smithy-types v0.43.0 (*) │   ├── aws-types v0.13.0 (*) ├── aws-sdk-cloudfront v0.13.0 │   ├── aws-endpoint v0.13.0 (*) │   ├── aws-http v0.13.0 (*) │   ├── aws-sig-auth v0.13.0 (*) │   ├── aws-smithy-async v0.43.0 (*) │   ├── aws-smithy-client v0.43.0 (*) │   ├── aws-smithy-http v0.43.0 (*) │   ├── aws-smithy-http-tower v0.43.0 (*) │   ├── aws-smithy-types v0.43.0 (*) │   ├── aws-smithy-xml v0.43.0 (*) │   ├── aws-types v0.13.0 (*) ├── aws-sdk-dynamodb v0.13.0 │   ├── aws-endpoint v0.13.0 (*) │   ├── aws-http v0.13.0 (*) │   ├── aws-sig-auth v0.13.0 (*) │   ├── aws-smithy-async v0.43.0 (*) │   ├── aws-smithy-client v0.43.0 (*) │   ├── aws-smithy-http v0.43.0 (*) │   ├── aws-smithy-http-tower v0.43.0 (*) │   ├── aws-smithy-json v0.43.0 (*) │   ├── aws-smithy-types v0.43.0 (*) │   ├── aws-types v0.13.0 (*) ├── aws-sdk-sqs v0.13.0 │   ├── aws-endpoint v0.13.0 (*) │   ├── aws-http v0.13.0 (*) │   ├── aws-sig-auth v0.13.0 (*) │   ├── aws-smithy-async v0.43.0 (*) │   ├── aws-smithy-client v0.43.0 (*) │   ├── aws-smithy-http v0.43.0 (*) │   ├── aws-smithy-http-tower v0.43.0 (*) │   ├── aws-smithy-query v0.43.0 (*) │   ├── aws-smithy-types v0.43.0 (*) │   ├── aws-smithy-xml v0.43.0 (*) │   ├── aws-types v0.13.0 (*) ├── aws-smithy-http v0.43.0 (*) ├── aws-smithy-types v0.43.0 (*) ├── aws-types v0.13.0 (*) ├── aws-smithy-client v0.43.0 (*)
    

    Environment details (OS name and version, etc.)

    Mac

    Logs

    ERROR lambda_runtime: SdkError("request has timed out: API call (single attempt) timeout occurred after 30ms")

    bug 
    opened by ymwjbxxq 20
  • The SDK sends empty session tokens if `AWS_SESSION_TOKEN` is set but empty

    The SDK sends empty session tokens if `AWS_SESSION_TOKEN` is set but empty

    Bug Report

    Version

    │   ├── aws-sdk-sts v0.0.26-alpha
    ├── aws-sdk-secretsmanager v0.0.26-alpha
    

    Platform

    Linux a491cb647fd0 4.19.121-linuxkit #1 SMP Tue Dec 1 17:50:32 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
    

    AWS Services

    Secrets Manager

    Description

    I'm trying to build lambda function for docker custom runtime. When binary built with cargo build --release aws_sdk_secretsmanager works just fine, but for amazon/aws-lambda-provided:al2 I need to build it with --target x86_64-unknown-linux-musl.

    In that way the secretsmanager clinet request always returns UnrecognizedClientException

    {
        "code": "UnrecognizedClientException",
        "message": "The security token included in the request is invalid.",
        "request_id": "..."
    }
    

    Files for reproducing

    main.rs

    use tokio;
    
    
    #[tokio::main]
    async fn main() -> Result<(), Box<dyn std::error::Error>> {
        let aws_cfg = &aws_config::from_env().load().await;
        let sm_client = aws_sdk_secretsmanager::Client::new(&aws_cfg);
        match sm_client.get_secret_value().secret_id("secret-value").send().await {
            Ok(v) => {
                let secret = v.secret_string.unwrap().to_string();
                println!("{}", secret);
            },
            Err(e) => {
                eprintln!("{}", e);
            }
        };
    
    
        Ok(())
    }
    

    Cargo.toml

    [package]
    name = "sm-test"
    version = "0.1.0"
    edition = "2021"
    
    [dependencies]
    aws-config = "0.0.26-alpha"
    aws-sdk-secretsmanager = "0.0.26-alpha"
    tokio = { version = "1", features = ["full"] }
    

    function.sh

    function handler () {
      ./sm-test
    }
    

    bootstrap

    #!/bin/sh
    
    set -euo pipefail
    
    # Initialization - load function handler
    source $LAMBDA_TASK_ROOT/"$(echo $_HANDLER | cut -d. -f1).sh"
    # Processing
    while true
    do
      HEADERS="$(mktemp)"
      # Get an event. The HTTP request will block until one is received
      EVENT_DATA=$(curl -sS -LD "$HEADERS" -X GET "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next")
    
      # Extract request ID by scraping response headers received above
      REQUEST_ID=$(grep -Fi Lambda-Runtime-Aws-Request-Id "$HEADERS" | tr -d '[:space:]' | cut -d: -f2)
    
      # Run the handler function from the script
      RESPONSE=$($(echo "$_HANDLER" | cut -d. -f3) "$EVENT_DATA") # -f3 gets the handler function name from function.sh.handler
    
      # Send the response
      curl -X POST "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response"  -d "$RESPONSE"
    done
    

    Dockerfile

    FROM rust:slim as builder
    
    ENV DEBIAN_FRONTEND noninteractive
    ENV PKG_CONFIG_SYSROOT_DIR=/
    ENV PKG_CONFIG_ALLOW_CROSS=1
    
    COPY Cargo.toml Cargo.toml
    COPY Cargo.lock Cargo.lock
    COPY src/*.rs src/
    
    RUN rustup target add x86_64-unknown-linux-musl
    RUN apt-get update -y && apt-get install -y musl-tools libssl-dev pkg-config build-essential
    RUN cargo build --release --locked --target x86_64-unknown-linux-musl
    
    
    FROM amazon/aws-lambda-provided:al2 as runtime
    
    ENV TESTS_FOLDER=/var/task
    ENV AWS_DEFAULT_REGION=us-west-2
    ENV AWS_DEFAULT_OUTPUT=json
    
    WORKDIR ${TESTS_FOLDER}
    
    COPY bootstrap /var/runtime/bootstrap
    COPY function.sh ${TESTS_FOLDER}/function.sh
    COPY --from=builder ./target/x86_64-unknown-linux-musl/release/sm-test ${TESTS_FOLDER}/sm-test
    
    RUN chmod 755 ${TESTS_FOLDER}/function.sh && \
        chmod 755 /var/runtime/bootstrap
    
    CMD [ "function.sh.handler" ]
    

    lambda.env

    AWS_ACCESS_KEY_ID=
    AWS_SECRET_ACCESS_KEY=
    RUST_BACKTRACE=full
    
    docker build -t smtest .
    docker run --env-file lambda.env -p 9000:8080 smtest:latest
    
    curl -XPOST "http://localhost:9000/2015-03-31/functions/function/invocations" -d '{}'
    

    Expected Print secret-value

    Actual

    {
        "code": "UnrecognizedClientException",
        "message": "The security token included in the request is invalid.",
        "request_id": "..."
    }
    

    Notes

    s3 client built with musl works without issue

    bug 
    opened by gtach2o 16
  • Please add support for local installation of SDK

    Please add support for local installation of SDK

    On top to the versioning issues I ran into in #93, I also noticed that the project currently doesn't support running cargo install for local installation:

    [ 1689s] + cd aws-sdk-rust-0.0.5+git+86cbc50
    [ 1689s] + cd sdk
    [ 1689s] + RUSTFLAGS='-Clink-arg=-Wl,-z,relro,-z,now -C debuginfo=2'
    [ 1689s] + cargo install --root=/home/abuild/rpmbuild/BUILDROOT/aws-sdk-rust-0.0.5+git+86cbc50-8.1.x86_64/usr --path .
    [ 1689s] warning: profiles for the non root package will be ignored, specify profiles at the workspace root:
    [ 1689s] package:   /home/abuild/rpmbuild/BUILD/aws-sdk-rust-0.0.5+git+86cbc50/sdk/examples/s3-helloworld/Cargo.toml
    [ 1689s] workspace: /home/abuild/rpmbuild/BUILD/aws-sdk-rust-0.0.5+git+86cbc50/sdk/Cargo.toml
    [ 1689s] error: found a virtual manifest at `/home/abuild/rpmbuild/BUILD/aws-sdk-rust-0.0.5+git+86cbc50/sdk/Cargo.toml` instead of a package manifest
    [ 1689s] error: Bad exit status from /var/tmp/rpm-tmp.QvzBLQ (%install)
    

    See: https://build.opensuse.org/package/live_build_log/home:glaubitz:branches:Cloud:Tools/aws-sdk-rust/openSUSE_Tumbleweed/x86_64

    Would it be possible to add support for cargo install in the future so that the Rust SDK can be packaged for Linux distributions?

    closed-for-staleness 
    opened by glaubitz 14
  • `ConstructionFailure(MissingCredentials)` when using IAM Roles attached to an instance

    `ConstructionFailure(MissingCredentials)` when using IAM Roles attached to an instance

    Describe the bug

    We are running an SQS client as a Kubernetes pod on EC2.

    When doing any SQS request, we get the following error:

    Error: ConstructionFailure(MissingCredentials)

    Expected Behavior

    According to the documentation in https://docs.aws.amazon.com/sdk-for-rust/latest/dg/credentials.html, the request should work because "IAM Roles attached to an instance" is supported.

    Current Behavior

    We tested the EC2 policy using the AWS command line, and we were able to query the SQS queue without API keys.

    We also have a number of services that access S3, and they also work correctly without API keys.

    Reproduction Steps

    I'm just building the client

            let mut conf = aws_config::load_from_env().await;
            let mut builder = aws_sdk_sqs::config::Builder::from(&conf);
            let client = aws_sdk_sqs::Client::from_conf(builder.build());
    

    and sending the request

    let get_url_resp = client.get_queue_url().queue_name("foo_queue").send().await?;
    

    Possible Solution

    No response

    Additional Information/Context

    No response

    Version

    ├── aws-config v0.47.0
    │   ├── aws-http v0.47.0
    │   │   ├── aws-smithy-http v0.47.0
    │   │   │   ├── aws-smithy-eventstream v0.47.0
    │   │   │   │   ├── aws-smithy-types v0.47.0
    │   │   │   ├── aws-smithy-types v0.47.0 (*)
    │   │   ├── aws-smithy-types v0.47.0 (*)
    │   │   ├── aws-types v0.47.0
    │   │   │   ├── aws-smithy-async v0.47.0
    │   │   │   ├── aws-smithy-client v0.47.0
    │   │   │   │   ├── aws-smithy-async v0.47.0 (*)
    │   │   │   │   ├── aws-smithy-http v0.47.0 (*)
    │   │   │   │   ├── aws-smithy-http-tower v0.47.0
    │   │   │   │   │   ├── aws-smithy-http v0.47.0 (*)
    │   │   │   │   ├── aws-smithy-types v0.47.0 (*)
    │   │   │   ├── aws-smithy-http v0.47.0 (*)
    │   │   │   ├── aws-smithy-types v0.47.0 (*)
    │   ├── aws-sdk-sso v0.17.0
    │   │   ├── aws-endpoint v0.47.0
    │   │   │   ├── aws-smithy-http v0.47.0 (*)
    │   │   │   ├── aws-types v0.47.0 (*)
    │   │   ├── aws-http v0.47.0 (*)
    │   │   ├── aws-sig-auth v0.47.0
    │   │   │   ├── aws-sigv4 v0.47.0
    │   │   │   │   ├── aws-smithy-eventstream v0.47.0 (*)
    │   │   │   │   ├── aws-smithy-http v0.47.0 (*)
    │   │   │   ├── aws-smithy-eventstream v0.47.0 (*)
    │   │   │   ├── aws-smithy-http v0.47.0 (*)
    │   │   │   ├── aws-types v0.47.0 (*)
    │   │   ├── aws-smithy-async v0.47.0 (*)
    │   │   ├── aws-smithy-client v0.47.0 (*)
    │   │   ├── aws-smithy-http v0.47.0 (*)
    │   │   ├── aws-smithy-http-tower v0.47.0 (*)
    │   │   ├── aws-smithy-json v0.47.0
    │   │   │   └── aws-smithy-types v0.47.0 (*)
    │   │   ├── aws-smithy-types v0.47.0 (*)
    │   │   ├── aws-types v0.47.0 (*)
    │   ├── aws-sdk-sts v0.17.0
    │   │   ├── aws-endpoint v0.47.0 (*)
    │   │   ├── aws-http v0.47.0 (*)
    │   │   ├── aws-sig-auth v0.47.0 (*)
    │   │   ├── aws-smithy-async v0.47.0 (*)
    │   │   ├── aws-smithy-client v0.47.0 (*)
    │   │   ├── aws-smithy-http v0.47.0 (*)
    │   │   ├── aws-smithy-http-tower v0.47.0 (*)
    │   │   ├── aws-smithy-query v0.47.0
    │   │   │   ├── aws-smithy-types v0.47.0 (*)
    │   │   ├── aws-smithy-types v0.47.0 (*)
    │   │   ├── aws-smithy-xml v0.47.0
    │   │   ├── aws-types v0.47.0 (*)
    │   ├── aws-smithy-async v0.47.0 (*)
    │   ├── aws-smithy-client v0.47.0 (*)
    │   ├── aws-smithy-http v0.47.0 (*)
    │   ├── aws-smithy-http-tower v0.47.0 (*)
    │   ├── aws-smithy-json v0.47.0 (*)
    │   ├── aws-smithy-types v0.47.0 (*)
    │   ├── aws-types v0.47.0 (*)
    ├── aws-sdk-s3 v0.17.0
    │   ├── aws-endpoint v0.47.0 (*)
    │   ├── aws-http v0.47.0 (*)
    │   ├── aws-sig-auth v0.47.0 (*)
    │   ├── aws-sigv4 v0.47.0 (*)
    │   ├── aws-smithy-async v0.47.0 (*)
    │   ├── aws-smithy-checksums v0.47.0
    │   │   ├── aws-smithy-http v0.47.0 (*)
    │   │   ├── aws-smithy-types v0.47.0 (*)
    │   ├── aws-smithy-client v0.47.0 (*)
    │   ├── aws-smithy-eventstream v0.47.0 (*)
    │   ├── aws-smithy-http v0.47.0 (*)
    │   ├── aws-smithy-http-tower v0.47.0 (*)
    │   ├── aws-smithy-types v0.47.0 (*)
    │   ├── aws-smithy-xml v0.47.0 (*)
    │   ├── aws-types v0.47.0 (*)
    ├── aws-sdk-sqs v0.17.0
    │   ├── aws-endpoint v0.47.0 (*)
    │   ├── aws-http v0.47.0 (*)
    │   ├── aws-sig-auth v0.47.0 (*)
    │   ├── aws-smithy-async v0.47.0 (*)
    │   ├── aws-smithy-client v0.47.0 (*)
    │   ├── aws-smithy-http v0.47.0 (*)
    │   ├── aws-smithy-http-tower v0.47.0 (*)
    │   ├── aws-smithy-query v0.47.0 (*)
    │   ├── aws-smithy-types v0.47.0 (*)
    │   ├── aws-smithy-xml v0.47.0 (*)
    │   ├── aws-types v0.47.0 (*)
    ├── aws-smithy-http v0.47.0 (*)
    ├── aws-types v0.47.0 (*)
    ├── aws_lambda_events v0.6.3
    
    
    
    ### Environment details (OS name and version, etc.)
    
    Debian instance on EC2
    
    ### Logs
    
    _No response_
    bug 
    opened by albx79 13
  • Override Config aws-smithy-client

    Override Config aws-smithy-client

    Describe the feature

    Hi all,

    as a follow-up of this issue https://github.com/awslabs/aws-sdk-rust/issues/558 where we can set the timeout for the client to be latency aware with the retries

    #[tokio::main]
    async fn main() -> Result<(), Error> {
        tracing_subscriber::fmt()
            .with_ansi(false)
            .without_time()
            .with_max_level(tracing_subscriber::filter::LevelFilter::DEBUG)
            .init();
    
        let timeout_config = timeout::Config::new()
            .with_api_timeouts(
                timeout::Api::new()
                    .with_call_timeout(TriState::Set(Duration::from_millis(150)))
                    .with_call_attempt_timeout(TriState::Set(Duration::from_millis(50))),
            );
        let config = aws_config::from_env()
            .retry_config(RetryConfig::new().with_max_attempts(3))
            .timeout_config(timeout_config)
    
            .load()
            .await;
    
        let dynamodb_client = aws_sdk_dynamodb::Client::new(&config);
    

    I have noticed the following:

    DEBUG aws_smithy_client::retry: attempt 1 failed with Error(TransientError); retrying after 435.692227ms

    And the aws-smithy-client/src/retry.rs is configured as:

    const MAX_ATTEMPTS: u32 = 3;
    const INITIAL_RETRY_TOKENS: usize = 500;
    const RETRY_COST: usize = 5;
    

    And I have no way to overwrite the default parameters.

    From the test, I cannot get exactly where the initial value of the backoff is coming from https://github.com/awslabs/smithy-rs/blob/a0539e20b069a7de021c84521d8f3c7ba098ad6d/rust-runtime/aws-smithy-client/src/retry.rs#L276

    It seems to me that this line of code is not correct:

    let backoff = b * (r.pow(self.local.attempts - 1) as f64);
    let backoff = Duration::from_secs_f64(backoff).min(self.config.max_backoff);
    

    Because:

    1. it does not consider a value to calculate the retry
    2. convert all in seconds with a max of 20s

    It should be based on milliseconds https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=7deed195b0811c97887dbcd6c98f1a6e

    let exponential_delay = (ms * (r.pow(attempts - 1) as f64)) as u64;
    let backoff =  Duration::from_millis(exponential_delay).min(Duration::from_secs(20));
    

    If we can pass the backoff value it could become

    let retry_config = RetryConfig::new()
      .with_max_attempts(5);
      .with_backoff_delay(100); //ms
    

    Use Case

    When you are latency aware, you should be able to overwrite the default parameters to configure the backoff.

    In my configuration case, I have the following:

    • 3 retries
    • 50ms a for a single attempt
    • overall duration 150ms

    the back-off moves the second retry after 435.692227ms DEBUG aws_smithy_client::retry: attempt 1 failed with Error(TransientError); retrying after 435.692227ms

    This means that it will never retry a second time.

    Proposed Solution

    Be able to overwrite the backoff policy.

    If I wish to have this configuration

    • 3 retries
    • 50ms a for a single attempt

    I could setup the backoff policy at 10ms. For example, I would have the following after the first failed attempt.

    Retry 1 -> retrying after 20ms Retry 2 -> retrying after 40ms Retry 3 -> retrying after 60ms

    Now I can setup my overall duration "with_call_timeout" to 210ms, giving the retries time to happen.

    Other Information

    No response

    Acknowledgements

    • [ ] I may be able to implement this feature request
    • [ ] This feature might incur a breaking change

    A note for the community

    Community Note

    • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
    • Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
    • If you are interested in working on this issue, please leave a comment
    feature-request 
    opened by ymwjbxxq 12
  • Unable to Compile aws-config

    Unable to Compile aws-config

    Confirm by changing [ ] to [x] below:

    Platform/OS/Device What are you running the sdk on? MacOsX

    Describe the question I'm no longer able to compile the AWS SDK due to the following errors:

    error[E0277]: the trait bound `aws_smithy_http::operation::SerializationError: From<Infallible>` is not satisfied
       --> /Users/sarmst22/.cargo/registry/src/github.com-1ecc6299db9ec823/aws-sdk-sts-0.0.22-alpha/src/input.rs:531:76
        |
    531 |                 aws_smithy_http::operation::BuildError::SerializationError(err.into())
        |                                                                            ^^^^^^^^^^ the trait `From<Infallible>` is not implemented for `aws_smithy_http::operation::SerializationError`
        |
        = note: required because of the requirements on the impl of `Into<aws_smithy_http::operation::SerializationError>` for `Infallible`
    

    I was compiling earlier, which is why this is so confusing, the following is a section of my cargo.toml of the crates in the SDK I 'm using:

    aws-config = "0.0.24-alpha"
    aws-sdk-sqs = "0.0.24-alpha"
    aws-types = "0.0.24-alpha"
    aws-smithy-client = {version = "0.27.0-alpha.2", features=["rustls"]}
    

    The intellisense in vs code mentions the following

    could not compile `aws-config`
    

    Is this a bug? Or is this an issue with my current combination of crate versions?

    guidance 
    opened by sarmst22 12
  • [request]: I wish DynamoDB fluent builders implemented `Clone`

    [request]: I wish DynamoDB fluent builders implemented `Clone`

    Community Note

    • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
    • Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
    • If you are interested in working on this issue, please leave a comment

    It would help me if DynamoDB fluent builders implemented Clone.

    I've encountered two points where I've wanted to be able to clone fluent builders.

    1. When trying to scan a table and go through all the pages.
      • It would be helpful to be able to call .set_exclusive_start_key(...) and clone the Scan instance before calling .send() to get the next page so that the Scan instance could be re-used to get the next page.
      • Currently, I have to build a new Scan instance for every page.
    2. When updating many items, and you encounter errors that should be retried (500s, ThrottlingExceptions, etc).
      • It would be nice to be able to clone the UpdateItem and just retry the .send() call.
      • Currently, I have to build a new UpdateItem for every attempt.

    I'm sure I will find more cases when being able to clone a struct from that module would be useful. I've only been using the SDK for two days.

    good first issue feature-request pending-release 
    opened by dcormier 12
  • Please avoid dash in version numbers to avoid issues with packagers

    Please avoid dash in version numbers to avoid issues with packagers

    I just started working on packaging aws-sdk-rust for openSUSE/SLE as a small side project and noticed that upstream is using a dash in the version number to add the "alpha" prefix.

    Since Linux package managers use the dash to separate upstream version and package revision numbers, the dash should not be used for versioning in upstream projects.

    Could you maybe instead use + or ~, e.g. 0.0.5~alpha to avoid this issue in the future?

    closing-soon 
    opened by glaubitz 12
  • Excessive memory usage when calling PutObject

    Excessive memory usage when calling PutObject

    Describe the bug

    We have observed high memory usage when uploading large files to S3. The problem is compounded when performing multiple concurrent uploads and also when increasing the buffer size (as needed to achieve desired level of throughput to S3). Particularly, we need as many as 25 parallel uploads, which can result in several gigabyte of memory usage due to aws-sdk-rust alone. This is unexpected.

    Expected Behavior

    Memory usage should be ~20MB for a single PutObject call.

    Current Behavior

    Memory usage can reach 500MiB for a single PutObject call.

    Reproduction Steps

    main.rs

    extern crate bytesize;
    
    use std::time::Duration;
    
    use anyhow::Result;
    use aws_sdk_s3::{Client, Region};
    use aws_sdk_s3::types::ByteStream;
    use bytesize::ByteSize;
    use sysinfo::{get_current_pid, ProcessExt, System, SystemExt};
    use tokio::time;
    
    #[tokio::main]
    async fn main() -> Result<()> {
        let pid = get_current_pid().unwrap();
        tokio::spawn(async move {
            let mut system = System::new();
    
            let mut interval = time::interval(Duration::from_secs(1));
            loop {
                interval.tick().await;
                system.refresh_process(pid);
                if let Some(process) = system.process(pid) {
                    let memory = process.memory();
                    println!("Memory usage: {}", ByteSize::b(memory).to_string());
                }
            }
        });
    
        println!("Sleeping for a few seconds before starting upload");
        time::sleep(Duration::from_secs(3)).await;
    
        let sdk_config = aws_config::from_env()
            .region(Region::new("us-east-1"))
            .load()
            .await;
    
        let s3_client = Client::new(&sdk_config);
    
        println!("Starting upload");
    
        s3_client.put_object()
            .bucket("my-bucket")
            .key("test")
            .body(ByteStream::read_from()
                .path("1gb.txt")
                .buffer_size(128 * 1024)
                .build()
                .await?)
            .send()
            .await?;
    
        Ok(())
    }
    

    cargo.toml

    [package]
    name = "s3-put-object-test"
    version = "0.1.0"
    edition = "2021"
    
    [dependencies]
    anyhow = "1.0"
    aws-config = "0.49"
    aws-sdk-s3 = "0.19"
    bytesize = "1.1"
    sysinfo = "0.26"
    tokio = { version = "1", features = ["full"] }
    

    Output (Local machine, home internet)

    Sleeping for a few seconds before starting upload
    Memory usage: 4.5 MB
    Memory usage: 4.7 MB
    Memory usage: 4.7 MB
    Memory usage: 6.1 MB
    Starting upload
    Memory usage: 18.4 MB
    Memory usage: 73.0 MB
    Memory usage: 98.6 MB
    Memory usage: 117.9 MB
    Memory usage: 134.1 MB
    Memory usage: 147.9 MB
    Memory usage: 159.9 MB
    Memory usage: 170.4 MB
    Memory usage: 179.2 MB
    Memory usage: 187.9 MB
    Memory usage: 193.9 MB
    Memory usage: 197.9 MB
    Memory usage: 199.7 MB
    Memory usage: 200.2 MB
    Memory usage: 200.4 MB
    Memory usage: 200.4 MB
    Memory usage: 200.5 MB
    Memory usage: 200.5 MB
    Memory usage: 200.5 MB
    Memory usage: 200.6 MB
    Memory usage: 200.6 MB
    Memory usage: 201.2 MB
    Memory usage: 137.8 MB
    Memory usage: 132.8 MB
    Memory usage: 144.9 MB
    Memory usage: 145.9 MB
    Memory usage: 146.8 MB
    Memory usage: 146.8 MB
    Memory usage: 138.4 MB
    Memory usage: 130.1 MB
    Memory usage: 121.7 MB
    Memory usage: 121.7 MB
    Memory usage: 121.7 MB
    Memory usage: 121.7 MB
    Memory usage: 124.0 MB
    Memory usage: 125.0 MB
    Memory usage: 125.1 MB
    Memory usage: 125.1 MB
    Memory usage: 116.8 MB
    Memory usage: 116.8 MB
    Memory usage: 116.8 MB
    Memory usage: 117.0 MB
    Memory usage: 118.8 MB
    Memory usage: 118.9 MB
    Memory usage: 118.9 MB
    Memory usage: 118.9 MB
    Memory usage: 119.7 MB
    Memory usage: 119.7 MB
    Memory usage: 119.7 MB
    Memory usage: 119.7 MB
    Memory usage: 119.7 MB
    Memory usage: 119.7 MB
    Memory usage: 119.7 MB
    Memory usage: 119.7 MB
    Memory usage: 119.9 MB
    Memory usage: 119.9 MB
    

    Output (c6i.xlarge, repro app compiled with --release, cold page cache)

    $ ./target/release/s3-put-object-test 
    Sleeping for a few seconds before starting upload
    Memory usage: 4.5 MB
    Memory usage: 4.5 MB
    Memory usage: 4.5 MB
    Memory usage: 4.5 MB
    Starting upload
    Memory usage: 104.7 MB
    Memory usage: 184.0 MB
    Memory usage: 202.1 MB
    Memory usage: 216.7 MB
    Memory usage: 226.5 MB
    Memory usage: 254.5 MB
    Memory usage: 263.9 MB
    Memory usage: 243.9 MB
    Memory usage: 243.9 MB
    

    Output (c6i.xlarge, repro app compiled with --release, warm page cache)

    $ ./target/release/s3-put-object-test 
    Sleeping for a few seconds before starting upload
    Memory usage: 4.8 MB
    Memory usage: 4.8 MB
    Memory usage: 4.8 MB
    Memory usage: 4.8 MB
    Starting upload
    Memory usage: 265.5 MB
    Memory usage: 375.5 MB
    Memory usage: 499.4 MB
    Memory usage: 465.9 MB
    Memory usage: 348.7 MB
    

    Possible Solution

    No response

    Additional Information/Context

    No response

    Version

    ├── aws-config v0.49.0
    │   ├── aws-http v0.49.0
    │   │   ├── aws-smithy-http v0.49.0
    │   │   │   ├── aws-smithy-eventstream v0.49.0
    │   │   │   │   ├── aws-smithy-types v0.49.0
    │   │   │   ├── aws-smithy-types v0.49.0 (*)
    │   │   ├── aws-smithy-types v0.49.0 (*)
    │   │   ├── aws-types v0.49.0
    │   │   │   ├── aws-smithy-async v0.49.0
    │   │   │   ├── aws-smithy-client v0.49.0
    │   │   │   │   ├── aws-smithy-async v0.49.0 (*)
    │   │   │   │   ├── aws-smithy-http v0.49.0 (*)
    │   │   │   │   ├── aws-smithy-http-tower v0.49.0
    │   │   │   │   │   ├── aws-smithy-http v0.49.0 (*)
    │   │   │   │   ├── aws-smithy-types v0.49.0 (*)
    │   │   │   ├── aws-smithy-http v0.49.0 (*)
    │   │   │   ├── aws-smithy-types v0.49.0 (*)
    │   ├── aws-sdk-sso v0.19.0
    │   │   ├── aws-endpoint v0.49.0
    │   │   │   ├── aws-smithy-http v0.49.0 (*)
    │   │   │   ├── aws-smithy-types v0.49.0 (*)
    │   │   │   ├── aws-types v0.49.0 (*)
    │   │   ├── aws-http v0.49.0 (*)
    │   │   ├── aws-sig-auth v0.49.0
    │   │   │   ├── aws-sigv4 v0.49.0
    │   │   │   │   ├── aws-smithy-eventstream v0.49.0 (*)
    │   │   │   │   ├── aws-smithy-http v0.49.0 (*)
    │   │   │   ├── aws-smithy-eventstream v0.49.0 (*)
    │   │   │   ├── aws-smithy-http v0.49.0 (*)
    │   │   │   ├── aws-types v0.49.0 (*)
    │   │   ├── aws-smithy-async v0.49.0 (*)
    │   │   ├── aws-smithy-client v0.49.0 (*)
    │   │   ├── aws-smithy-http v0.49.0 (*)
    │   │   ├── aws-smithy-http-tower v0.49.0 (*)
    │   │   ├── aws-smithy-json v0.49.0
    │   │   │   └── aws-smithy-types v0.49.0 (*)
    │   │   ├── aws-smithy-types v0.49.0 (*)
    │   │   ├── aws-types v0.49.0 (*)
    │   ├── aws-sdk-sts v0.19.0
    │   │   ├── aws-endpoint v0.49.0 (*)
    │   │   ├── aws-http v0.49.0 (*)
    │   │   ├── aws-sig-auth v0.49.0 (*)
    │   │   ├── aws-smithy-async v0.49.0 (*)
    │   │   ├── aws-smithy-client v0.49.0 (*)
    │   │   ├── aws-smithy-http v0.49.0 (*)
    │   │   ├── aws-smithy-http-tower v0.49.0 (*)
    │   │   ├── aws-smithy-query v0.49.0
    │   │   │   ├── aws-smithy-types v0.49.0 (*)
    │   │   ├── aws-smithy-types v0.49.0 (*)
    │   │   ├── aws-smithy-xml v0.49.0
    │   │   ├── aws-types v0.49.0 (*)
    │   ├── aws-smithy-async v0.49.0 (*)
    │   ├── aws-smithy-client v0.49.0 (*)
    │   ├── aws-smithy-http v0.49.0 (*)
    │   ├── aws-smithy-http-tower v0.49.0 (*)
    │   ├── aws-smithy-json v0.49.0 (*)
    │   ├── aws-smithy-types v0.49.0 (*)
    │   ├── aws-types v0.49.0 (*)
    ├── aws-sdk-s3 v0.19.0
    │   ├── aws-endpoint v0.49.0 (*)
    │   ├── aws-http v0.49.0 (*)
    │   ├── aws-sig-auth v0.49.0 (*)
    │   ├── aws-sigv4 v0.49.0 (*)
    │   ├── aws-smithy-async v0.49.0 (*)
    │   ├── aws-smithy-checksums v0.49.0
    │   │   ├── aws-smithy-http v0.49.0 (*)
    │   │   ├── aws-smithy-types v0.49.0 (*)
    │   ├── aws-smithy-client v0.49.0 (*)
    │   ├── aws-smithy-eventstream v0.49.0 (*)
    │   ├── aws-smithy-http v0.49.0 (*)
    │   ├── aws-smithy-http-tower v0.49.0 (*)
    │   ├── aws-smithy-types v0.49.0 (*)
    │   ├── aws-smithy-xml v0.49.0 (*)
    │   ├── aws-types v0.49.0 (*)
    

    Environment details (OS name and version, etc.)

    MacOS 12.6 (Monterey); Also observed on linux servers

    Logs

    No response

    bug 
    opened by exabytes18 10
  • [request]: Could aws_config::Config implement Clone?

    [request]: Could aws_config::Config implement Clone?

    Tell us about your request

    Could aws_config::Config implement Clone?

    Tell us about the problem you're trying to solve.

    I'd like to await the call to load in one place and then pass the resulting object around in places where managing the lifetime would be annoying.

    Are you currently working around this issue?

    We currently have our own version of aws_config::Config in MaterializeInc/materialize that does support Clone: https://github.com/MaterializeInc/materialize/blob/8ea7ff3af8c842e3e54105d585fdf8b4b1f8b4ab/src/aws-util/src/config.rs#L18-L24. This opens us up to issues like https://github.com/awslabs/aws-sdk-rust/issues/317.

    Additional context

    https://github.com/awslabs/smithy-rs/issues/364 seems related?

    feature-request pending-release 
    opened by benesch 10
  • Timout warnings

    Timout warnings

    Confirm by changing [ ] to [x] below:

    Platform/OS/Device Ubuntu Linux 20.04.3 SDK version: 0.0.26-alpha

    Describe the question

        let cw_cfg = aws_sdk_cloudwatch::Config::builder() 
            .region(aws_sdk_sts::Region::new(
                aws_credentials.get("AWS_DEFAULT_REGION").unwrap().clone(),
            ))
            .credentials_provider(credentials_provider)
            .timeout_config(Default::default())
            .build();
    

    When I post metrics I keep getting these warnings, I added the timeout_config(Default::default()), but doesn't seem to make any difference.

    2021-11-30T19:22:55.184303Z  WARN aws_smithy_client::timeout: One or more timeouts were set but no async_sleep fn was passed. No timeouts will occur.
    Timeouts:
    Connect (time to first byte):(unset)
    TLS negotiation:(unset)
    HTTP read:(unset)
    API requests:(unset)
    HTTP requests:(unset)
    

    What do I need to configure to get rid of these warnings?

    bug 
    opened by fredrik-jansson-se 10
  • aws-sdk-lambda Environment Builder accepting an IntoIterator

    aws-sdk-lambda Environment Builder accepting an IntoIterator

    Describe the feature

    https://docs.rs/aws-sdk-lambda/latest/aws_sdk_lambda/model/environment/struct.Builder.html

    Currently, the set_variables accepts an Option<HashMap>.

    It would be more ergonomic if it accepted (or had an option to accept) an Option<IntoIterator<Item=(String, String)>> so as not to limit inputs to just HashMaps. Eg BTreeMap.

    Use Case

    Ergonomics of passing in environments.

    Proposed Solution

    You could change the existing impl to an IntoIterator or add another broader implementation method that takes in an iterator.

    Other Information

    No response

    Acknowledgements

    • [ ] I may be able to implement this feature request
    • [ ] This feature might incur a breaking change

    A note for the community

    Community Note

    • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
    • Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
    • If you are interested in working on this issue, please leave a comment
    feature-request p2 
    opened by nipunn1313 1
  • S3 PutObject: Set content length with a stream hyper Body for checksum

    S3 PutObject: Set content length with a stream hyper Body for checksum

    Describe the bug

    Hi there! We would want to set the content_length (as size_hint) with a streaming hyper:Body to upload an object to S3 with it's checksum.

    Expected Behavior

    Upload the streaming body with it's checksum to S3.

    Current Behavior

    Fail with a message like Only request bodies with a known size can be checksum validated coming from there

    Reproduction Steps

    We are doing something like:

    
    async upload(from: Box<(dyn io::AsyncRead + Unpin + Send + Sync + 'static)>, from_size_bytes: i64)
            let body = hyper::Body::wrap_stream(tokio_util::io::ReaderStream::new(from));
            let bytes_stream = ByteStream::new(SdkBody::from(body));
    
            self.client
                .put_object()
                .bucket(self.bucket_name.clone())
                .key(to.0.to_owned())
                .set_metadata(metadata.map(|m| m.0))
                .checksum_algorithm(ChecksumAlgorithm::Sha256)
                .content_length(from_size_bytes) <--- a try to size_hint
                .body(bytes_stream)
                .send()
                .await
                .map_err(|e| {
                    metrics::inc_put_object_fail();
                    e
                })?;
    

    In Rusoto we used new_with_size to specify the size_hint in the body stream.

    Possible Solution

    No response

    Additional Information/Context

    No response

    Version

    ├── aws-config v0.51.0
    │   ├── aws-http v0.51.0
    │   │   ├── aws-smithy-http v0.51.0
    │   │   │   ├── aws-smithy-eventstream v0.51.0
    │   │   │   │   ├── aws-smithy-types v0.51.0
    │   │   │   ├── aws-smithy-types v0.51.0 (*)
    │   │   ├── aws-smithy-types v0.51.0 (*)
    │   │   ├── aws-types v0.51.0
    │   │   │   ├── aws-smithy-async v0.51.0
    │   │   │   ├── aws-smithy-client v0.51.0
    │   │   │   │   ├── aws-smithy-async v0.51.0 (*)
    │   │   │   │   ├── aws-smithy-http v0.51.0 (*)
    │   │   │   │   ├── aws-smithy-http-tower v0.51.0
    │   │   │   │   │   ├── aws-smithy-http v0.51.0 (*)
    │   │   │   │   ├── aws-smithy-types v0.51.0 (*)
    │   │   │   ├── aws-smithy-http v0.51.0 (*)
    │   │   │   ├── aws-smithy-types v0.51.0 (*)
    │   ├── aws-sdk-sso v0.21.0
    │   │   ├── aws-endpoint v0.51.0
    │   │   │   ├── aws-smithy-http v0.51.0 (*)
    │   │   │   ├── aws-smithy-types v0.51.0 (*)
    │   │   │   ├── aws-types v0.51.0 (*)
    │   │   ├── aws-http v0.51.0 (*)
    │   │   ├── aws-sig-auth v0.51.0
    │   │   │   ├── aws-sigv4 v0.51.0
    │   │   │   │   ├── aws-smithy-eventstream v0.51.0 (*)
    │   │   │   │   ├── aws-smithy-http v0.51.0 (*)
    │   │   │   ├── aws-smithy-eventstream v0.51.0 (*)
    │   │   │   ├── aws-smithy-http v0.51.0 (*)
    │   │   │   ├── aws-types v0.51.0 (*)
    │   │   ├── aws-smithy-async v0.51.0 (*)
    │   │   ├── aws-smithy-client v0.51.0 (*)
    │   │   ├── aws-smithy-http v0.51.0 (*)
    │   │   ├── aws-smithy-http-tower v0.51.0 (*)
    │   │   ├── aws-smithy-json v0.51.0
    │   │   │   └── aws-smithy-types v0.51.0 (*)
    │   │   ├── aws-smithy-types v0.51.0 (*)
    │   │   ├── aws-types v0.51.0 (*)
    │   ├── aws-sdk-sts v0.21.0
    │   │   ├── aws-endpoint v0.51.0 (*)
    │   │   ├── aws-http v0.51.0 (*)
    │   │   ├── aws-sig-auth v0.51.0 (*)
    │   │   ├── aws-smithy-async v0.51.0 (*)
    │   │   ├── aws-smithy-client v0.51.0 (*)
    │   │   ├── aws-smithy-http v0.51.0 (*)
    │   │   ├── aws-smithy-http-tower v0.51.0 (*)
    │   │   ├── aws-smithy-query v0.51.0
    │   │   │   ├── aws-smithy-types v0.51.0 (*)
    │   │   ├── aws-smithy-types v0.51.0 (*)
    │   │   ├── aws-smithy-xml v0.51.0
    │   │   ├── aws-types v0.51.0 (*)
    │   ├── aws-smithy-async v0.51.0 (*)
    │   ├── aws-smithy-client v0.51.0 (*)
    │   ├── aws-smithy-http v0.51.0 (*)
    │   ├── aws-smithy-http-tower v0.51.0 (*)
    │   ├── aws-smithy-json v0.51.0 (*)
    │   ├── aws-smithy-types v0.51.0 (*)
    │   ├── aws-types v0.51.0 (*)
    ├── aws-sdk-s3 v0.21.0
    │   ├── aws-endpoint v0.51.0 (*)
    │   ├── aws-http v0.51.0 (*)
    │   ├── aws-sig-auth v0.51.0 (*)
    │   ├── aws-sigv4 v0.51.0 (*)
    │   ├── aws-smithy-async v0.51.0 (*)
    │   ├── aws-smithy-checksums v0.51.0
    │   │   ├── aws-smithy-http v0.51.0 (*)
    │   │   ├── aws-smithy-types v0.51.0 (*)
    │   ├── aws-smithy-client v0.51.0 (*)
    │   ├── aws-smithy-eventstream v0.51.0 (*)
    │   ├── aws-smithy-http v0.51.0 (*)
    │   ├── aws-smithy-http-tower v0.51.0 (*)
    │   ├── aws-smithy-types v0.51.0 (*)
    │   ├── aws-smithy-xml v0.51.0 (*)
    │   ├── aws-types v0.51.0 (*)
    ├── aws-smithy-http v0.51.0 (*)
    ├── aws-types v0.51.0 (*)
    

    Environment details (OS name and version, etc.)

    Linux localhost 5.15.0-48-generic #54-Ubuntu SMP Fri Aug 26 13:26:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

    Logs

    No response

    bug p2 
    opened by andresrsanchez 2
  • Add support for EventBridge Scheduler

    Add support for EventBridge Scheduler

    Describe the feature

    EventBridge Scheduler is a new feature that was just released.

    Use Case

    I'd love to start using this new service!

    Proposed Solution

    No response

    Other Information

    No response

    Acknowledgements

    • [ ] I may be able to implement this feature request
    • [ ] This feature might incur a breaking change

    A note for the community

    Community Note

    • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
    • Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
    • If you are interested in working on this issue, please leave a comment
    feature-request p2 
    opened by fermanjj 2
  • Missing Credentials when running in docker

    Missing Credentials when running in docker

    Describe the bug

    No Errors are thrown when building the client, and all the required variables(access_token, secret_key, ....) loaded properly from env(checked with printing out loaded config), but when trying to get object, returns Error MissingCredentials

    I have Windows 11, and it is working fine if I run it on windows, but on docker it throws this

    Dockerfile

    FROM rust:latest as planner
    WORKDIR /app
    RUN cargo install cargo-chef
    COPY . .
    RUN cargo chef prepare --recipe-path recipe.json
    
    FROM rust:latest as cacher
    WORKDIR /app
    RUN cargo install cargo-chef
    COPY --from=planner /app/recipe.json recipe.json
    RUN cargo chef cook --release --recipe-path recipe.json
    
    FROM rust:latest as builder
    
    COPY . /app
    WORKDIR /app
    COPY --from=cacher /app/target target
    COPY --from=cacher /usr/local/cargo /usr/local/cargo
    RUN cargo build --release
    
    FROM gcr.io/distroless/cc-debian11
    
    COPY --from=builder /app/target/release/test /app/test
    WORKDIR /app
    
    EXPOSE 8080
    
    CMD ["./test"]
    

    Expected Behavior

    Work as usual, no MissingCredentials

    Current Behavior

    throws MissingCredentials (when run in docker)

    Reproduction Steps

    just make a simple get object request, use the given dockerfile, and run it,

    NOTE: I'm not using AWS S3, I'm using CloudFlare R2, but I don't think that would make any difference.

        dotenv::dotenv().ok();
        let end_point_url = std::env::var("aws_endpoint").unwrap();
    
        let ep = aws_sdk_s3::Endpoint::immutable(Uri::from_str(end_point_url.as_str()).unwrap());
        let config_loaded_from_env = aws_config::load_from_env().await;
        let config = aws_sdk_s3::config::Builder::from(&config_loaded_from_env)
            .retry_config(aws_config::retry::RetryConfig::disabled())
            .endpoint_resolver(ep)
            .build();
    
        let client = Arc::new(aws_sdk_s3::Client::from_conf(config));
        let object = s3_client
            .get_object()
            .bucket(bucket_name)
            .key(key)
            .send().await;
    

    Possible Solution

    No response

    Additional Information/Context

    No response

    Version

    `cargo tree | FINDSTR aws-`
    
    ????????? aws-config v0.51.0
    ???   ????????? aws-http v0.51.0
    ???   ???   ????????? aws-smithy-http v0.51.0
    ???   ???   ???   ????????? aws-smithy-eventstream v0.51.0
    ???   ???   ???   ???   ????????? aws-smithy-types v0.51.0
    ???   ???   ???   ????????? aws-smithy-types v0.51.0 (*)
    ???   ???   ????????? aws-smithy-types v0.51.0 (*)
    ???   ???   ????????? aws-types v0.51.0
    ???   ???   ???   ????????? aws-smithy-async v0.51.0
    ???   ???   ???   ????????? aws-smithy-client v0.51.0
    ???   ???   ???   ???   ????????? aws-smithy-async v0.51.0 (*)
    ???   ???   ???   ???   ????????? aws-smithy-http v0.51.0 (*)
    ???   ???   ???   ???   ????????? aws-smithy-http-tower v0.51.0
    ???   ???   ???   ???   ???   ????????? aws-smithy-http v0.51.0 (*)
    ???   ???   ???   ???   ????????? aws-smithy-types v0.51.0 (*)
    ???   ???   ???   ????????? aws-smithy-http v0.51.0 (*)
    ???   ???   ???   ????????? aws-smithy-types v0.51.0 (*)
    ???   ????????? aws-sdk-sso v0.21.0
    ???   ???   ????????? aws-endpoint v0.51.0
    ???   ???   ???   ????????? aws-smithy-http v0.51.0 (*)
    ???   ???   ???   ????????? aws-smithy-types v0.51.0 (*)
    ???   ???   ???   ????????? aws-types v0.51.0 (*)
    ???   ???   ????????? aws-http v0.51.0 (*)
    ???   ???   ????????? aws-sig-auth v0.51.0
    ???   ???   ???   ????????? aws-sigv4 v0.51.0
    ???   ???   ???   ???   ????????? aws-smithy-eventstream v0.51.0 (*)
    ???   ???   ???   ???   ????????? aws-smithy-http v0.51.0 (*)
    ???   ???   ???   ????????? aws-smithy-eventstream v0.51.0 (*)
    ???   ???   ???   ????????? aws-smithy-http v0.51.0 (*)
    ???   ???   ???   ????????? aws-types v0.51.0 (*)
    ???   ???   ????????? aws-smithy-async v0.51.0 (*)
    ???   ???   ????????? aws-smithy-client v0.51.0 (*)
    ???   ???   ????????? aws-smithy-http v0.51.0 (*)
    ???   ???   ????????? aws-smithy-http-tower v0.51.0 (*)
    ???   ???   ????????? aws-smithy-json v0.51.0
    ???   ???   ???   ????????? aws-smithy-types v0.51.0 (*)
    ???   ???   ????????? aws-smithy-types v0.51.0 (*)
    ???   ???   ????????? aws-types v0.51.0 (*)
    ???   ????????? aws-sdk-sts v0.21.0
    ???   ???   ????????? aws-endpoint v0.51.0 (*)
    ???   ???   ????????? aws-http v0.51.0 (*)
    ???   ???   ????????? aws-sig-auth v0.51.0 (*)
    ???   ???   ????????? aws-smithy-async v0.51.0 (*)
    ???   ???   ????????? aws-smithy-client v0.51.0 (*)
    ???   ???   ????????? aws-smithy-http v0.51.0 (*)
    ???   ???   ????????? aws-smithy-http-tower v0.51.0 (*)
    ???   ???   ????????? aws-smithy-query v0.51.0
    ???   ???   ???   ????????? aws-smithy-types v0.51.0 (*)
    ???   ???   ????????? aws-smithy-types v0.51.0 (*)
    ???   ???   ????????? aws-smithy-xml v0.51.0
    ???   ???   ????????? aws-types v0.51.0 (*)
    ???   ????????? aws-smithy-async v0.51.0 (*)
    ???   ????????? aws-smithy-client v0.51.0 (*)
    ???   ????????? aws-smithy-http v0.51.0 (*)
    ???   ????????? aws-smithy-http-tower v0.51.0 (*)
    ???   ????????? aws-smithy-json v0.51.0 (*)
    ???   ????????? aws-smithy-types v0.51.0 (*)
    ???   ????????? aws-types v0.51.0 (*)
    ????????? aws-sdk-s3 v0.21.0
    ???   ????????? aws-endpoint v0.51.0 (*)
    ???   ????????? aws-http v0.51.0 (*)
    ???   ????????? aws-sig-auth v0.51.0 (*)
    ???   ????????? aws-sigv4 v0.51.0 (*)
    ???   ????????? aws-smithy-async v0.51.0 (*)
    ???   ????????? aws-smithy-checksums v0.51.0
    ???   ???   ????????? aws-smithy-http v0.51.0 (*)
    ???   ???   ????????? aws-smithy-types v0.51.0 (*)
    ???   ????????? aws-smithy-client v0.51.0 (*)
    ???   ????????? aws-smithy-eventstream v0.51.0 (*)
    ???   ????????? aws-smithy-http v0.51.0 (*)
    ???   ????????? aws-smithy-http-tower v0.51.0 (*)
    ???   ????????? aws-smithy-types v0.51.0 (*)
    ???   ????????? aws-smithy-xml v0.51.0 (*)
    ???   ????????? aws-types v0.51.0 (*)
    

    Environment details (OS name and version, etc.)

    Windows 11 22H2 x64
    rustc 1.64.0 (a55dd71d5 2022-09-19)
    
    bug p2 
    opened by ash-hashtag 3
  • S3 SignatureDoesNotMatch

    S3 SignatureDoesNotMatch

    Describe the bug

    In this glue example, I am uploading a .py script for the crawler to run.

    https://github.com/DavidSouther/aws-doc-sdk-examples/blob/4815350f9994b84e552d51672dd5dc544e53ee5c/rust_dev_preview/glue/src/bin/scenario.rs#L256-L266

    2022-11-09T00:33:49.221508Z TRACE prepare_job:send_operation{operation="PutObject" service="s3"}: aws_sigv4::http_request::sign: canonical_request=PUT
    /%2Frust-glue-mvp-53e51165-1cbb-47b1-bd10-d0bf8f726450-bucket/job.py
    x-id=PutObject
    content-length:3157
    content-type:application/octet-stream
    host:s3.us-east-1.amazonaws.com
    x-amz-content-sha256:UNSIGNED-PAYLOAD
    x-amz-date:20221109T003349Z
    x-amz-user-agent:aws-sdk-rust/0.51.0 api/s3/0.21.0 os/macos lang/rust/1.65.0
    
    content-length;content-type;host;x-amz-content-sha256;x-amz-date;x-amz-user-agent
    UNSIGNED-PAYLOAD
    
    ...
    
    2022-11-09T00:33:49.301059Z TRACE prepare_job:send_operation{operation="PutObject" service="s3"}:load_response: aws_smithy_http::middleware: http_response=Response { status: 403, version: HTTP/1.1, headers: {"x-amz-request-id": "58QER2YAQD6GX0TH", "x-amz-id-2": "jzvNyWzH933f6CUgunszWXtmwx7xNftjy9NxWlMiesgCbjgYu19DwikK0ZPWEe6FzXHWEasCFOc=", "content-type": "application/xml", "transfer-encoding": "chunked", "date": "Wed, 09 Nov 2022 00:33:48 GMT", "server": "AmazonS3", "connection": "close"}, body: b"<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<Error><Code>SignatureDoesNotMatch</Code><Message>The request signature we calculated does not match the signature you provided. Check your key and signing method.</Message><AWSAccessKeyId>AKIAZTHI4CYE3PXHLYMJ</AWSAccessKeyId><StringToSign>AWS4-HMAC-SHA256\n20221109T003349Z\n20221109/us-east-1/s3/aws4_request\nfcd623245a6d82d72cbcdcbb96516abcb255eb87f1535f63d04f89cf28c8929e</StringToSign><SignatureProvided>f1f7a993b438935d3ba91007aee28b37742e3b5e2e9c55e3df198351da54124b</SignatureProvided><StringToSignBytes>    [... 133 bytes ...]     </StringToSignBytes><CanonicalRequest>PUT\n//rust-glue-mvp-53e51165-1cbb-47b1-bd10-d0bf8f726450-bucket/job.py\nx-id=PutObject\ncontent-length:3157\ncontent-type:application/octet-stream\nhost:s3.us-east-1.amazonaws.com\nx-amz-content-sha256:UNSIGNED-PAYLOAD\nx-amz-date:20221109T003349Z\nx-amz-user-agent:aws-sdk-rust/0.51.0 api/s3/0.21.0 os/macos lang/rust/1.65.0\n\ncontent-length;content-type;host;x-amz-content-sha256;x-amz-date;x-amz-user-agent\nUNSIGNED-PAYLOAD</CanonicalRequest><CanonicalRequestBytes>     [...418 bytes...]     </CanonicalRequestBytes><RequestId>58QER2YAQD6GX0TH</RequestId><HostId>jzvNyWzH933f6CUgunszWXtmwx7xNftjy9NxWlMiesgCbjgYu19DwikK0ZPWEe6FzXHWEasCFOc=</HostId></Error>" }
    

    Expected Behavior

    PutObject to succeed with no errors.

    Current Behavior

    PutObject is erroring with signature mismatches.

    Reproduction Steps

    src/main.rs (or src/bin/ssccee.rs)

    use aws_config;
    use aws_sdk_s3::types::ByteStream;
    
    #[tokio::main]
    pub async fn main() {
        let sdk_config = aws_config::load_from_env().await;
        let s3 = aws_sdk_s3::Client::new(&sdk_config);
        let bucket = format!("test-bucket-{}", uuid::Uuid::new_v4());
        let create_bucket = s3
            .create_bucket()
            .bucket(bucket)
            .send()
            .await
            .expect("create bucket");
    
        let bucket = create_bucket
            .location()
            .expect("Failed to get created bucket");
    
        s3.put_object()
            .bucket(bucket)
            .key("job.py")
            .body(
                ByteStream::from_path("resources/flight_etl_job_script.py".to_string())
                    .await
                    .expect("reading job python"),
            )
            .send()
            .await
            .expect("Uploaded object");
    }
    
    # Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
    # SPDX-License-Identifier: Apache-2.0
    
    print("Hello, world")
    

    Possible Solution

    No response

    Additional Information/Context

    No response

    Version

    glue-code-examples v0.1.0 (/Users/dpsouth/devel/aws/aws-doc-sdk-examples/rust_dev_preview/glue)
    ├── aws-config v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd)
    │   ├── aws-http v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd)
    │   │   ├── aws-smithy-http v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd)
    │   │   │   ├── aws-smithy-eventstream v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd)
    │   │   │   │   ├── aws-smithy-types v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd)
    │   │   │   ├── aws-smithy-types v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   │   ├── aws-smithy-types v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   │   ├── aws-types v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd)
    │   │   │   ├── aws-smithy-async v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd)
    │   │   │   ├── aws-smithy-client v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd)
    │   │   │   │   ├── aws-smithy-async v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   │   │   │   ├── aws-smithy-http v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   │   │   │   ├── aws-smithy-http-tower v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd)
    │   │   │   │   │   ├── aws-smithy-http v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   │   │   │   ├── aws-smithy-types v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   │   │   ├── aws-smithy-http v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   │   │   ├── aws-smithy-types v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   ├── aws-sdk-sso v0.21.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd)
    │   │   ├── aws-endpoint v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd)
    │   │   │   ├── aws-smithy-http v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   │   │   ├── aws-smithy-types v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   │   │   ├── aws-types v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   │   ├── aws-http v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   │   ├── aws-sig-auth v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd)
    │   │   │   ├── aws-sigv4 v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd)
    │   │   │   │   ├── aws-smithy-eventstream v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   │   │   │   ├── aws-smithy-http v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   │   │   ├── aws-smithy-eventstream v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   │   │   ├── aws-smithy-http v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   │   │   ├── aws-types v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   │   ├── aws-smithy-async v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   │   ├── aws-smithy-client v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   │   ├── aws-smithy-http v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   │   ├── aws-smithy-http-tower v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   │   ├── aws-smithy-json v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd)
    │   │   │   └── aws-smithy-types v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   │   ├── aws-smithy-types v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   │   ├── aws-types v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   ├── aws-sdk-sts v0.21.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd)
    │   │   ├── aws-endpoint v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   │   ├── aws-http v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   │   ├── aws-sig-auth v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   │   ├── aws-smithy-async v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   │   ├── aws-smithy-client v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   │   ├── aws-smithy-http v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   │   ├── aws-smithy-http-tower v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   │   ├── aws-smithy-query v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd)
    │   │   │   ├── aws-smithy-types v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   │   ├── aws-smithy-types v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   │   ├── aws-smithy-xml v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd)
    │   │   ├── aws-types v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   ├── aws-smithy-async v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   ├── aws-smithy-client v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   ├── aws-smithy-http v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   ├── aws-smithy-http-tower v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   ├── aws-smithy-json v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   ├── aws-smithy-types v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   ├── aws-types v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    ├── aws-http v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    ├── aws-sdk-glue v0.21.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd)
    │   ├── aws-endpoint v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   ├── aws-http v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   ├── aws-sig-auth v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   ├── aws-smithy-async v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   ├── aws-smithy-client v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   ├── aws-smithy-http v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   ├── aws-smithy-http-tower v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   ├── aws-smithy-json v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   ├── aws-smithy-types v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   ├── aws-types v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    ├── aws-sdk-s3 v0.21.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd)
    │   ├── aws-endpoint v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   ├── aws-http v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   ├── aws-sig-auth v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   ├── aws-sigv4 v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   ├── aws-smithy-async v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   ├── aws-smithy-checksums v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd)
    │   │   ├── aws-smithy-http v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   │   ├── aws-smithy-types v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   ├── aws-smithy-client v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   ├── aws-smithy-eventstream v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   ├── aws-smithy-http v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   ├── aws-smithy-http-tower v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   ├── aws-smithy-types v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   ├── aws-smithy-xml v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    │   ├── aws-types v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    ├── aws-smithy-client v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    ├── aws-smithy-http v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    ├── aws-smithy-types v0.51.0 (https://github.com/awslabs/aws-sdk-rust?branch=main#557778dd) (*)
    

    Environment details (OS name and version, etc.)

    macOS Monterey Version 12.6.1 Apple M1 Pro

    Logs

    No response

    bug p2 
    opened by DavidSouther 3
  • SQS send_message is not working

    SQS send_message is not working

    Describe the bug

    Following this example provided https://github.com/awslabs/aws-sdk-rust/blob/main/examples/sqs/src/bin/sqs-hello-world.rs

    I tried to send a simple SQSMessage but it never worked. Also, it seems that any other expression or statement which is specified after the send request, are not working working.

    Expected Behavior

    Sqs send should be able to send messages.

    Current Behavior

    let rsp = client
            .send_message()
            .queue_url(queue_url)
            .message_body(&message.body)
            .message_group_id(&message.group)
            // If the queue is FIFO, you need to set .message_deduplication_id
            // or configure the queue for ContentBasedDeduplication.
            .send()
            .await?;
    
    println!("Send message to the queue: {:#?}", rsp);
    

    In the given code, firstly the send() is not working. I couldn't see any messages in the standard queue. Secondly, the lines after this send are not getting called. Not even the println! ()

    Reproduction Steps

    let rsp = client
            .send_message()
            .queue_url(queue_url)
            .message_body(&message.body)
            .message_group_id(&message.group)
            // If the queue is FIFO, you need to set .message_deduplication_id
            // or configure the queue for ContentBasedDeduplication.
            .send()
            .await?;
    
        println!("Send message to the queue: {:#?}", rsp);
    

    Or you can follow the code in this link to replicate the behavior. https://github.com/awslabs/aws-sdk-rust/blob/main/examples/sqs/src/bin/sqs-hello-world.rs

    Possible Solution

    No response

    Additional Information/Context

    No response

    Version

    [dependencies]
    aws-config = "0.51.0"
    aws-sdk-sqs = "0.21.0"
    tokio = { version = "1", features = ["full"] }
    

    Environment details (OS name and version, etc.)

    Windows 10, VSCode, 64bit

    Logs

    No response

    bug p2 
    opened by leogitpub 1
Releases(release-2022-10-26)
  • release-2022-10-26(Oct 26, 2022)

    Breaking Changes:

    • ⚠ (smithy-rs#1825) Bump MSRV to be 1.62.0.
    • ⚠ (smithy-rs#1740, smithy-rs#256) The SDK, by default, now times out if socket connect or time to first byte read takes longer than 3.1 seconds. There are a large number of breaking changes that come with this change that may affect you if you customize the client configuration at all. See the upgrade guide for information on how to configure timeouts, and how to resolve compilation issues after upgrading.

    New this release:

    • 🎉 (aws-sdk-rust#237, smithy-rs#1770) It is now possible to programmatically customize the locations of the profile config/credentials files in aws-config:
      use aws_config::profile::{ProfileFileCredentialsProvider, ProfileFileRegionProvider};
      use aws_config::profile::profile_file::{ProfileFiles, ProfileFileKind};
      
      let profile_files = ProfileFiles::builder()
          .with_file(ProfileFileKind::Credentials, "some/path/to/credentials-file")
          .build();
      let credentials_provider = ProfileFileCredentialsProvider::builder()
          .profile_files(profile_files.clone())
          .build();
      let region_provider = ProfileFileRegionProvider::builder()
          .profile_files(profile_files)
          .build();
      
      let sdk_config = aws_config::from_env()
          .credentials_provider(credentials_provider)
          .region(region_provider)
          .load()
          .await;
      
    • 🐛 (smithy-rs#1740, smithy-rs#256) Setting connect/read timeouts with SdkConfig now works. Previously, these timeout config values were lost during connector creation, so the only reliable way to set them was to manually override the HTTP connector.
    • 🐛 (aws-sdk-rust#620, smithy-rs#1748) Paginators now stop on encountering a duplicate token by default rather than panic. This behavior can be customized by toggling the stop_on_duplicate_token property on the paginator before calling send.
    • 🐛 (smithy-rs#1747, @kastolars) The client Config now has getters for every value that it holds.
    • 🐛 (smithy-rs#1822, @kevinpark1217) Fix regression where connect_timeout and read_timeout fields are unused in the IMDS client
    • (aws-sdk-rust#625, @kevinpark1217) Ability to override the IMDS client in DefaultCredentialsChain
    • 🐛 (smithy-rs#1656) Fix aws-sigv4 canonical request formatting fallibility.
    • (smithy-rs#1890) Add test to exercise excluded headers in aws-sigv4.

    Contributors Thank you for your contributions! ❤

    Source code(tar.gz)
    Source code(zip)
  • release-2022-10-13(Oct 13, 2022)

  • release-2022-09-21(Sep 21, 2022)

    Breaking Changes:

    • ⚠ (smithy-rs#1603, aws-sdk-rust#586) aws_config::RetryConfig no longer implements Default, and its new function has been replaced with standard.
    • ⚠ (smithy-rs#1603, aws-sdk-rust#586) Direct configuration of aws_config::SdkConfig now defaults to retries being disabled. If you're using aws_config::load_from_env() or aws_config::from_env() to configure the SDK, then you are NOT affected by this change. If you use SdkConfig::builder() to configure the SDK, then you ARE affected by this change and should set the retry config on that builder.
    • ⚠ (smithy-rs#1603, aws-sdk-rust#586) Client creation now panics if retries or timeouts are enabled without an async sleep implementation set on the SDK config. If you're using the Tokio runtime and have the rt-tokio feature enabled (which is enabled by default), then you shouldn't notice this change at all. Otherwise, if using something other than Tokio as the async runtime, the AsyncSleep trait must be implemented, and that implementation given to the config builder via the sleep_impl method. Alternatively, retry can be explicitly turned off by setting the retry config to RetryConfig::disabled(), which will result in successful client creation without an async sleep implementation.
    • ⚠ (smithy-rs#1715, smithy-rs#1717) ClassifyResponse was renamed to ClassifyRetry and is no longer implemented for the unit type.
    • ⚠ (smithy-rs#1715, smithy-rs#1717) The with_retry_policy and retry_policy functions on aws_smithy_http::operation::Operation have been renamed to with_retry_classifier and retry_classifier respectively. Public member retry_policy on aws_smithy_http::operation::Parts has been renamed to retry_classifier.

    New this release:

    • 🎉 (smithy-rs#1647, smithy-rs#1112) Implemented customizable operations per RFC-0017.

      Before this change, modifying operations before sending them required using lower-level APIs:

      let input = SomeOperationInput::builder().some_value(5).build()?;
      
      let operation = {
          let op = input.make_operation(&service_config).await?;
          let (request, response) = op.into_request_response();
      
          let request = request.augment(|req, _props| {
              req.headers_mut().insert(
                  HeaderName::from_static("x-some-header"),
                  HeaderValue::from_static("some-value")
              );
              Result::<_, Infallible>::Ok(req)
          })?;
      
          Operation::from_parts(request, response)
      };
      
      let response = smithy_client.call(operation).await?;
      

      Now, users may easily modify operations before sending with the customize method:

      let response = client.some_operation()
          .some_value(5)
          .customize()
          .await?
          .mutate_request(|mut req| {
              req.headers_mut().insert(
                  HeaderName::from_static("x-some-header"),
                  HeaderValue::from_static("some-value")
              );
          })
          .send()
          .await?;
      
    • 🐛 (smithy-rs#966, smithy-rs#1718) The AWS STS SDK now automatically retries IDPCommunicationError when calling AssumeRoleWithWebIdentity

    • 🐛 (aws-sdk-rust#303, smithy-rs#1717) The SdkError::ResponseError, typically caused by a connection terminating before the full response is received, is now treated as a transient failure and retried.

    Source code(tar.gz)
    Source code(zip)
  • release-2022-08-31(Aug 31, 2022)

    Breaking Changes:

    • ⚠ (smithy-rs#1641) Refactor endpoint resolution internals to use aws_smithy_types::Endpoint internally. The public internal functions aws_endpoint::set_endpoint_resolver and aws_endpoint::get_endpoint_resolver were removed.
    • 🐛⚠ (smithy-rs#1274) Lossy converters into integer types for aws_smithy_types::Number have been removed. Lossy converters into floating point types for aws_smithy_types::Number have been suffixed with _lossy. If you were directly using the integer lossy converters, we recommend you use the safe converters. Before:
      fn f1(n: aws_smithy_types::Number) {
          let foo: f32 = n.to_f32(); // Lossy conversion!
          let bar: u32 = n.to_u32(); // Lossy conversion!
      }
      

      After:

      fn f1(n: aws_smithy_types::Number) {
          use std::convert::TryInto; // Unnecessary import if you're using Rust 2021 edition.
          let foo: f32 = n.try_into().expect("lossy conversion detected"); // Or handle the error instead of panicking.
          // You can still do lossy conversions, but only into floating point types.
          let foo: f32 = n.to_f32_lossy();
          // To lossily convert into integer types, use an `as` cast directly.
          let bar: u32 = n as u32; // Lossy conversion!
      }
      
    • ⚠ (smithy-rs#1669) Bump MSRV from 1.58.1 to 1.61.0 per our policy.

    New this release:

    • 🎉 (smithy-rs#1598) Service configs are now generated with new accessors for:

      • Config::retry_config() - Returns a reference to the inner retry configuration.
      • Config::timeout_config() - Returns a reference to the inner timeout configuration.
      • Config::sleep_impl() - Returns a clone of the inner async sleep implementation.

      Previously, these were only accessible through SdkConfig.

    • 🐛🎉 (aws-sdk-rust#609) The AWS S3 GetObjectAttributes operation will no longer fail with an XML error.

    Source code(tar.gz)
    Source code(zip)
  • release-2022-08-08(Aug 9, 2022)

    Breaking Changes:

    • ⚠ (smithy-rs#1157) Rename EventStreamInput to EventStreamSender
    • ⚠ (smithy-rs#1157) The type of streaming unions that contain errors is generated without those errors. Errors in a streaming union Union are generated as members of the type UnionError. Taking Transcribe as an example, the AudioStream streaming union generates, in the client, both the AudioStream type:
      pub enum AudioStream {
          AudioEvent(crate::model::AudioEvent),
          Unknown,
      }
      

      and its error type,

      pub struct AudioStreamError {
          /// Kind of error that occurred.
          pub kind: AudioStreamErrorKind,
          /// Additional metadata about the error, including error code, message, and request ID.
          pub(crate) meta: aws_smithy_types::Error,
      }
      

      AudioStreamErrorKind contains all error variants for the union. Before, the generated code looked as:

      pub enum AudioStream {
          AudioEvent(crate::model::AudioEvent),
          ... all error variants,
          Unknown,
      }
      
    • ⚠ (smithy-rs#1157) aws_smithy_http::event_stream::EventStreamSender and aws_smithy_http::event_stream::Receiver are now generic over <T, E>, where T is a streaming union and E the union's errors. This means that event stream errors are now sent as Err of the union's error type. With this example model:
      @streaming union Event {
          throttlingError: ThrottlingError
      }
      @error("client") structure ThrottlingError {}
      

      Before:

      stream! { yield Ok(Event::ThrottlingError ...) }
      

      After:

      stream! { yield Err(EventError::ThrottlingError ...) }
      

      An example from the SDK is in transcribe streaming.

    New this release:

    • 🎉 (smithy-rs#1482) The AWS SDK for Rust now supports additional checksum algorithms for Amazon S3. When getting and putting objects, you may now request that the request body be validated with a checksum. The supported algorithms are SHA-1, SHA-256, CRC-32, and CRC-32C.

      #[tokio::main]
      async fn main() -> Result<(), Box<dyn std::error::Error>> {
          let sdk_config = aws_config::load_from_env().await;
          let s3_client = aws_sdk_s3::Client::new(&sdk_config);
          let body = aws_sdk_s3::types::ByteStream::read_from()
              .path(std::path::Path::new("./path/to/your/file.txt"))
              .build()
              .await
              .unwrap();
      
          let _ = s3_client
              .put_object()
              .bucket("your-bucket")
              .key("file.txt")
              .body(body)
              // When using this field, the checksum will be calculated for you
              .checksum_algorithm(aws_sdk_s3::model::ChecksumAlgorithm::Crc32C)
              .send()
              .await?;
      
          let body = aws_sdk_s3::types::ByteStream::read_from()
              .path(std::path::Path::new("./path/to/your/other-file.txt"))
              .build()
              .await
              .unwrap();
      
          let _ = s3_client
              .put_object()
              .bucket("your-bucket")
              .key("other-file.txt")
              .body(body)
              // Alternatively, you can pass a checksum that you've calculated yourself. It must be base64
              // encoded. Also, make sure that you're base64 encoding the bytes of the checksum, not its
              // string representation.
              .checksum_crc32_c(aws_smithy_types::base64::encode(&A_PRECALCULATED_CRC_32_C_CHECKSUM[..]))
              .send()
              .await?;
      }
      
    • 🎉 (smithy-rs#1571, smithy-rs#1385) SDK crate READMEs now include an example of creating a client

    • (smithy-rs#1573, smithy-rs#1569) Non-streaming struct members are now marked #[doc(hidden)] since they will be removed in the future

    Source code(tar.gz)
    Source code(zip)
  • release-2022-07-21(Jul 22, 2022)

    New this release:

    • 🎉 (smithy-rs#1457, @calavera) Re-export aws_types::SdkConfig in aws_config

    • 🎉 (aws-sdk-rust#581) Add From<aws_smithy_client::erase::DynConnector> impl for aws_smithy_client::http_connector::HttpConnector

    • 🎉 (aws-sdk-rust#567) Updated SDK Client retry behavior to allow for a configurable initial backoff. Previously, the initial backoff (named r in the code) was set to 2 seconds. This is not an ideal default for services like DynamoDB that expect clients to quickly retry failed request attempts. Now, users can set quicker (or slower) backoffs according to their needs.

      #[tokio::main]
      async fn main() -> Result<(), aws_sdk_dynamodb::Error> {
          let retry_config = aws_smithy_types::retry::RetryConfigBuilder::new()
              .max_attempts(4)
              .initial_backoff(Duration::from_millis(20));
      
          let shared_config = aws_config::from_env()
              .retry_config(retry_config)
              .load()
              .await;
      
          let client = aws_sdk_dynamodb::Client::new(&shared_config);
      
          // Given the 20ms backoff multiplier, and assuming this request fails 3 times before succeeding,
          // the first retry would take place between 0-20ms after the initial request,
          // the second retry would take place between 0-40ms after the first retry,
          // and the third retry would take place between 0-80ms after the second retry.
          let request = client
              .put_item()
              .table_name("users")
              .item("username", "Velfi")
              .item("account_type", "Developer")
              .send().await?;
      
          Ok(())
      }
      
    • 🎉 (smithy-rs#1557, aws-sdk-rust#580) The imds::Client in aws-config now implements Clone

    • 🐛 (smithy-rs#1541, @joshtriplett) Fix compilation of aws-config with rustls and native-tls disabled. The ProviderConfig::with_tcp_connector method uses aws_smithy_client::hyper_ext, which only exists with the client-hyper feature enabled. Add a feature enabling that, and enable it by default.

    • (smithy-rs#1263) Add support for aws-chunked content encoding. Only single-chunk encoding is supported. Multiple chunks and chunk signing are not supported at this time.

    • (smithy-rs#1540) Until now, SDK crates have all shared the exact same version numbers. This changes with this release. From now on, SDK crates will only version bump if they have changes. Coincidentally, they may share the same version number for some releases since changes to the code generator will cause a version bump in all of them, but this should not be relied upon.

    • 🐛 (smithy-rs#1559, aws-sdk-rust#582) Remove warning for valid IMDS provider use-case

    • 🐛 (smithy-rs#1558, aws-sdk-rust#583) Only emit a warning about failing to expand a ~ to the home directory in a profile file's path if that path was explicitly set (don't emit it for the default paths)

    • (smithy-rs#1556) The sleep_impl methods on the SdkConfig builder are now exposed and documented.

    Contributors Thank you for your contributions! ❤

    Source code(tar.gz)
    Source code(zip)
  • v0.15.0(Jun 29, 2022)

    Breaking Changes:

    • ⚠ (smithy-rs#932) Replaced use of pin-project with equivalent pin-project-lite. For pinned enum tuple variants and tuple structs, this change requires that we switch to using enum struct variants and regular structs. Most of the structs and enums that were updated had only private fields/variants and so have the same public API. However, this change does affect the public API of aws_smithy_http_tower::map_request::MapRequestFuture<F, E>. The Inner and Ready variants contained a single value. Each have been converted to struct variants and the inner value is now accessible by the inner field instead of the 0 field.

    New this release:

    • 🐛 (aws-sdk-rust#560, smithy-rs#1487) Add a trailing slash to the URI `/latest/meta-data/iam/security-credentials/ when loading credentials from IMDS
    • (aws-sdk-rust#540, @jmklix) Add comments for docker settings needed when using this sdk

    Contributors Thank you for your contributions! ❤

    Source code(tar.gz)
    Source code(zip)
  • v0.14.0(Jun 22, 2022)

    New this release:

    • 🐛 (aws-sdk-rust#547, smithy-rs#1458) Fix bug in profile file credential provider where a missing default profile lead to an unintended error.
    • (smithy-rs#1421) Add Debug implementation to several types in aws-config
    • 🐛 (aws-sdk-rust#558, smithy-rs#1478) Fix bug in retry policy where user configured timeouts were not retried. With this fix, setting with_call_attempt_timeout will lead to a retry when retries are enabled.
    • 🐛 (aws-sdk-rust#554) Requests to Route53 that return ResourceIds often come with a prefix. When passing those IDs directly into another request, the request would fail unless they manually stripped the prefix. Now, when making a request with a prefixed ID, the prefix will be stripped automatically.
    Source code(tar.gz)
    Source code(zip)
  • v0.13.0(Jun 9, 2022)

    New this release:

    • 🎉 (smithy-rs#1390) Add method ByteStream::into_async_read. This makes it easy to convert ByteStreams into a struct implementing tokio:io::AsyncRead. Available on crate feature rt-tokio only.
    • 🎉 (smithy-rs#1356, @jszwedko) Add support for credential_process in AWS configs for fetching credentials from an external process.
    • (smithy-rs#1404, @petrosagg) Switch to RustCrypto's implementation of MD5.

    Contributors Thank you for your contributions! ❤

    Source code(tar.gz)
    Source code(zip)
  • v0.12.0(May 13, 2022)

  • v0.11.0(Apr 29, 2022)

  • v0.10.1(Apr 14, 2022)

    Breaking Changes:

    New this release:

    Contributors Thank you for your contributions! ❤

    Source code(tar.gz)
    Source code(zip)
  • v0.9.0(Mar 17, 2022)

    Breaking Changes:

    • ⚠ (aws-sdk-rust#406) aws_types::config::Config has been renamed to aws_types::sdk_config::SdkConfig. This is to better differentiate it from service-specific configs like aws_sdk_s3::Config. If you were creating shared configs with aws_config::load_from_env(), then you don't have to do anything. If you were directly referring to a shared config, update your use statements and struct names.

      Before:

      use aws_types::config::Config;
      
      fn main() {
          let config = Config::builder()
          // config builder methods...
          .build()
          .await;
      }
      

      After:

      // We re-export this type from the root module so it's easier to reference
      use aws_types::SdkConfig;
      
      fn main() {
          let config = SdkConfig::builder()
          // config builder methods...
          .build()
          .await;
      }
      
    • ⚠ (smithy-rs#724) Timeout configuration has been refactored a bit. If you were setting timeouts through environment variables or an AWS profile, then you shouldn't need to change anything. Take note, however, that we don't currently support HTTP connect, read, write, or TLS negotiation timeouts. If you try to set any of those timeouts in your profile or environment, we'll log a warning explaining that those timeouts don't currently do anything.

      If you were using timeouts programmatically, you'll need to update your code. In previous versions, timeout configuration was stored in a single TimeoutConfig struct. In this new version, timeouts have been broken up into several different config structs that are then collected in a timeout::Config struct. As an example, to get the API per-attempt timeout in previous versions you would access it with <your TimeoutConfig>.api_call_attempt_timeout() and in this new version you would access it with <your timeout::Config>.api.call_attempt_timeout(). We also made some unimplemented timeouts inaccessible in order to avoid giving users the impression that setting them had an effect. We plan to re-introduce them once they're made functional in a future update.

    New this release:

    Source code(tar.gz)
    Source code(zip)
  • v0.8.0(Feb 24, 2022)

    Breaking Changes:

    • ⚠ (smithy-rs#1216) aws-sigv4 no longer skips the content-length and content-type headers when signing with SignatureLocation::QueryParams

    New this release:

    • 🎉 (smithy-rs#1220, aws-sdk-rust#462) Made it possible to change settings, such as load timeout, on the credential cache used by the DefaultCredentialsChain.
    • 🐛 (smithy-rs#1197) Fixed a bug that caused clients to eventually stop retrying. The cross-request retry allowance wasn't being reimbursed upon receiving a successful response, so once this allowance reached zero, no further retries would ever be attempted.
    • 🐛 (smithy-rs#1217, aws-sdk-rust#467) ClientBuilder helpers rustls() and native_tls() now return DynConnector so that they once again work when constructing clients with custom middleware in the SDK.
    • 🐛 (smithy-rs#1216, aws-sdk-rust#466) Fixed a bug in S3 that prevented the content-length and content-type inputs from being included in a presigned request signature. With this fix, customers can generate presigned URLs that enforce content-length and content-type for requests to S3.
    Source code(tar.gz)
    Source code(zip)
  • v0.7.0(Feb 21, 2022)

    0.7.0 (February 18th, 2022)

    Breaking Changes:

    • ⚠ (smithy-rs#1144) The aws_config::http_provider module has been renamed to aws_config::http_credential_provider to better reflect its purpose.

    • ⚠ (smithy-rs#1144) Some APIs required that timeout configuration be specified with an aws_smithy_client::timeout::Settings struct while others required an aws_smithy_types::timeout::TimeoutConfig struct. Both were equivalent. Now aws_smithy_types::timeout::TimeoutConfig is used everywhere and aws_smithy_client::timeout::Settings has been removed. Here's how to migrate code your code that depended on timeout::Settings:

      The old way:

      let timeout = timeout::Settings::new()
          .with_connect_timeout(Duration::from_secs(1))
          .with_read_timeout(Duration::from_secs(2));
      

      The new way:

      // This example is passing values, so they're wrapped in `Option::Some`. You can disable a timeout by passing `None`.
      let timeout = TimeoutConfig::new()
          .with_connect_timeout(Some(Duration::from_secs(1)))
          .with_read_timeout(Some(Duration::from_secs(2)));
      
    • ⚠ (smithy-rs#1144) MakeConnectorFn, HttpConnector, and HttpSettings have been moved from aws_config::provider_config to aws_smithy_client::http_connector. This is in preparation for a later update that will change how connectors are created and configured.

      If you were using these structs/enums, you can migrate your old code by importing them from their new location.

    • ⚠ (smithy-rs#1144) Along with moving HttpConnector to aws_smithy_client, the HttpConnector::make_connector method has been renamed to HttpConnector::connector.

      If you were using this method, you can migrate your old code by calling connector instead of make_connector.

    • ⚠ (smithy-rs#1085) Moved the following re-exports into a types module for all services:

      • aws_sdk_<service>::AggregatedBytes -> aws_sdk_<service>::types::AggregatedBytes
      • aws_sdk_<service>::Blob -> aws_sdk_<service>::types::Blob
      • aws_sdk_<service>::ByteStream -> aws_sdk_<service>::types::ByteStream
      • aws_sdk_<service>::DateTime -> aws_sdk_<service>::types::DateTime
      • aws_sdk_<service>::SdkError -> aws_sdk_<service>::types::SdkError
    • ⚠ (smithy-rs#1085) AggregatedBytes and ByteStream are now only re-exported if the service has streaming operations, and Blob/DateTime are only re-exported if the service uses them.

    • ⚠ (smithy-rs#1130) MSRV increased from 1.54 to 1.56.1 per our 2-behind MSRV policy.

    • ⚠ (smithy-rs#1132) Fluent clients for all services no longer have generics, and now use DynConnector and DynMiddleware to allow for connector/middleware customization. This should only break references to the client that specified generic types for it.

      If you customized the AWS client's connector or middleware with something like the following:

      let client = aws_sdk_s3::Client::with_config(
          aws_sdk_s3::client::Builder::new()
              .connector(my_custom_connector) // Connector customization
              .middleware(my_custom_middleware) // Middleware customization
              .default_async_sleep()
              .build(),
          config
      );
      

      Then you will need to wrap the custom connector or middleware in DynConnector and DynMiddleware respectively:

      let client = aws_sdk_s3::Client::with_config(
          aws_sdk_s3::client::Builder::new()
              .connector(DynConnector::new(my_custom_connector)) // Now with `DynConnector`
              .middleware(DynMiddleware::new(my_custom_middleware)) // Now with `DynMiddleware`
              .default_async_sleep()
              .build(),
          config
      );
      

      If you had functions that took a generic connector, such as the following:

      fn some_function<C, E>(conn: C) -> Result<()>
      where
          C: aws_smithy_client::bounds::SmithyConnector<Error = E> + Send + 'static,
          E: Into<aws_smithy_http::result::ConnectorError>
      {
          // ...
      }
      

      Then the generics and trait bounds will no longer be necessary:

      fn some_function(conn: DynConnector) -> Result<()> {
          // ...
      }
      

      Similarly, functions that took a generic middleware can replace the generic with DynMiddleware and remove their trait bounds.

    New this release:

    • 🐛 (aws-sdk-rust#443) The ProfileFileRegionProvider will now respect regions set in chained profiles
    • (smithy-rs#1144) Several modules defined in the aws_config crate that used to be declared within another module's file have been moved to their own files. The moved modules are sts, connector, and default_providers. They still have the exact same import paths.
    • 🐛 (smithy-rs#1129) Fix some docs links not working because they were escaped when they shouldn't have been
    • (smithy-rs#1085) The Client and Config re-exports now have their documentation inlined in the service docs
    • 🐛 (smithy-rs#1180) Fixed example showing how to use hardcoded credentials in aws-types
    Source code(tar.gz)
    Source code(zip)
  • v0.6.0(Jan 26, 2022)

  • v0.5.2(Jan 21, 2022)

  • v0.5.1(Jan 20, 2022)

  • v0.5.0(Jan 19, 2022)

    New this release:

    Contributors Thank you for your contributions! ❤

    Source code(tar.gz)
    Source code(zip)
  • v0.4.1(Jan 10, 2022)

    New this release:

    • 🐛 (smithy-rs#1050, @nmoutschen) Fix typos for X-Ray trace ID environment variable in aws_http::recursion_detection
    • 🐛 (smithy-rs#1054, aws-sdk-rust#391) Fix critical paginator bug where an empty outputToken lead to a never ending stream.

    Contributors Thank you for your contributions! ❤

    • @nmoutschen (smithy-rs#1050)
    Source code(tar.gz)
    Source code(zip)
  • v0.4.0(Jan 6, 2022)

    Breaking Changes:

    • ⚠ (smithy-rs#990) Codegen will no longer produce builders and clients with methods that take impl Into<T> except for strings and boxed types.
    • ⚠ (smithy-rs#961) The meta, environment, and dns Cargo feature flags were removed from aws-config. The code behind the dns flag is now enabled when rt-tokio is enabled. The code behind the meta and environment flags is always enabled now.
    • ⚠ (smithy-rs#1003) aws_http::AwsErrorRetryPolicy was moved to aws_http::retry::AwsErrorRetryPolicy.
    • ⚠ (smithy-rs#1017, smithy-rs#930) Simplify features in aws-config. All features have been removed from aws-config with the exception of: rt-tokio, rustls and native-tls. All other features are now included by default. If you depended on those features specifically, remove them from your features listing.

    New this release:

    • 🎉 (aws-sdk-rust#47, smithy-rs#1006) Add support for paginators! Paginated APIs now include .into_paginator() and (when supported) .into_paginator().items() to enable paginating responses automatically. The paginator API should be considered in preview and is subject to change pending customer feedback.
    • (smithy-rs#712) We removed an example 'telephone-game' that was problematic for our CI. The APIs that that example demonstrated are also demonstrated by our Polly and TranscribeStreaming examples so please check those out if you miss it.
    • 🐛 (aws-sdk-rust#357) Generated docs should no longer contain links that don't go anywhere
    • (aws-sdk-rust#254, @jacco) Made fluent operation structs cloneable
    • (smithy-rs#973) Debug implementation of Credentials will print expiry in a human readable way.
    • 🐛 (smithy-rs#999, smithy-rs#143, aws-sdk-rust#344) Add Route53 customization to trim /hostedzone/ prefix prior to serialization. This fixes a bug where round-tripping a hosted zone id resulted in an error.
    • 🐛 (smithy-rs#998, aws-sdk-rust#359) Fix bug where ECS credential provider could not perform retries.
    • (smithy-rs#1003) Add recursion detection middleware to the default stack
    • (smithy-rs#1002, aws-sdk-rust#352) aws_types::Config is now Clone
    • (smithy-rs#670, @jacco) Example for Config builder region function added
    • (smithy-rs#1021, @kiiadi) Add function to aws_config::profile::ProfileSet that allows listing of loaded profiles by name.
    • 🐛 (smithy-rs#1046, aws-sdk-rust#384) Fix IMDS credentials provider bug where the instance profile name was incorrectly cached.

    Contributors Thank you for your contributions! ❤

    • @jacco (aws-sdk-rust#254, smithy-rs#670)
    • @kiiadi (smithy-rs#1021)
    Source code(tar.gz)
    Source code(zip)
  • v0.3.0(Dec 16, 2021)

    Breaking Changes:

    • ⚠ (smithy-rs#930) If you directly depend on AWS or Smithy runtime crates (e.g., AWS crates not named aws-config or prefixed with aws-sdk-), the formerly default features from those crates must now be explicitly set in your Cargo.toml.

      Upgrade guide

      | before | after | |---------------------------------|-------| | aws-smithy-async = "VERSION" | aws-smithy-async = { version = "VERSION", features = ["rt-tokio"] } | | aws-smithy-client = "VERSION" | aws-smithy-client = { version = "VERSION", features = ["client-hyper", "rustls", "rt-tokio"] } | | aws-smithy-http = "VERSION" | aws-smithy-http = { version = "VERSION", features = ["rt-tokio"] } |

    • ⚠ (smithy-rs#940) aws_hyper::Client which was just a re-export of aws_smithy_types::Client with generics set has been removed. If you used aws_hyper::Client or aws_hyper::Client::https() you can update your code to use aws_smithy_client::Builder::https().

    • ⚠ (smithy-rs#947) The features aws-hyper/rustls and aws-hyper/native-tls have been removed. If you were using these, use the identical features on aws-smithy-client.

    • ⚠ (smithy-rs#959, smithy-rs#934) aws-hyper::AwsMiddleware is now generated into generated service clients directly. If you used aws_hyper::Middleware, use ::middleware::DefaultMiddleware` instead.

    New this release:

    • 🐛 (aws-sdk-rust#330) A bug that occurred when signing certain query strings has been fixed
    • 🐛 (smithy-rs#949, @a-xp) Fix incorrect argument order in the builder for LazyCachingCredentialsProvider
    • 🐛 (aws-sdk-rust#304) aws-config will now work as intended for users that want to use native-tls instead of rustls. Previously, it was difficult to ensure that rustls was not in use. Also, there is now an example of how to use native-tls and a test that ensures rustls is not in the dependency tree
    • 🐛 (aws-sdk-rust#317, smithy-rs#907) Removed inaccurate log message when a client was used without a sleep implementation, and improved context and call to action in logged messages around missing sleep implementations.
    • (smithy-rs#923) Use provided sleep_impl for retries instead of using Tokio directly.
    • (smithy-rs#920) Fix typos in module documentation for generated crates
    • 🐛 (aws-sdk-rust#301, smithy-rs#892) Avoid serializing repetitive xmlns attributes when serializing XML. This reduces the length of serialized requests and should improve compatibility with localstack.
    • 🐛 (smithy-rs#953, aws-sdk-rust#331) Fixed a bug where certain characters caused a panic during URI encoding.

    Contributors Thank you for your contributions! ❤

    • @a-xp (smithy-rs#949)
    Source code(tar.gz)
    Source code(zip)
  • v0.2.0(Dec 2, 2021)

    This release was a version bump to fix a version number conflict on crates.io while releasing 0.1.0. The changes in 0.1.0 were: New this release

    • Add docs.rs metadata section to all crates to document all features
    • Added a new example showing how to set all currently supported timeouts
    • Add a new check so that the SDK doesn't emit an irrelevant $HOME dir warning when running in a Lambda (aws-sdk-rust#307)
    • :bug: Don't capture empty session tokens from the AWS_SESSION_TOKEN environment variable (aws-sdk-rust#316, smithy-rs#906)
    Source code(tar.gz)
    Source code(zip)
  • v0.1.0(Dec 2, 2021)

  • v0.0.26-alpha(Nov 24, 2021)

    Breaking Changes

    • RetryConfigBuilder::merge_with has been renamed to RetryConfigBuilder::take_unset_from
    • Credentials::from_keys is now behind a feature flag named hardcoded-credentials in aws-types. It is NOT secure to hardcode credentials into your application, and the credentials providers that come with the AWS SDK should be preferred. (smithy-rs#875, smithy-rs#317)
    • (aws-smithy-client): Extraneous pub use SdkSuccess removed from aws_smithy_client::hyper_ext. (smithy-rs#855)
    • The add_metadata function was removed from AwsUserAgent in aws-http. Use with_feature_metadata, with_config_metadata, or with_framework_metadata now instead. (smithy-rs#865)
    • Several breaking changes around aws_smithy_types::Instant were introduced by smithy-rs#849:
      • aws_smithy_types::Instant from was renamed to DateTime to avoid confusion with the standard library's monotonically nondecreasing Instant type.
      • DateParseError in aws_smithy_types has been renamed to DateTimeParseError to match the type that's being parsed.
      • The chrono-conversions feature and associated functions have been moved to the aws-smithy-types-convert crate.
        • Calls to Instant::from_chrono should be changed to:
          use aws_smithy_types::DateTime;
          use aws_smithy_types_convert::date_time::DateTimeExt;
          
          // For chrono::DateTime<Utc>
          let date_time = DateTime::from_chrono_utc(chrono_date_time);
          // For chrono::DateTime<FixedOffset>
          let date_time = DateTime::from_chrono_offset(chrono_date_time);
          
        • Calls to instant.to_chrono() should be changed to:
          use aws_smithy_types_convert::date_time::DateTimeExt;
          
          date_time.to_chrono_utc();
          
      • Instant::from_system_time and Instant::to_system_time have been changed to From trait implementations.
        • Calls to from_system_time should be changed to:
          DateTime::from(system_time);
          // or
          let date_time: DateTime = system_time.into();
          
        • Calls to to_system_time should be changed to:
          SystemTime::from(date_time);
          // or
          let system_time: SystemTime = date_time.into();
          
      • Several functions in Instant/DateTime were renamed:
        • Instant::from_f64 -> DateTime::from_secs_f64
        • Instant::from_fractional_seconds -> DateTime::from_fractional_secs
        • Instant::from_epoch_seconds -> DateTime::from_secs
        • Instant::from_epoch_millis -> DateTime::from_millis
        • Instant::epoch_fractional_seconds -> DateTime::as_secs_f64
        • Instant::has_nanos -> DateTime::has_subsec_nanos
        • Instant::epoch_seconds -> DateTime::secs
        • Instant::epoch_subsecond_nanos -> DateTime::subsec_nanos
        • Instant::to_epoch_millis -> DateTime::to_millis
      • The DateTime::fmt method is now fallible and fails when a DateTime's value is outside what can be represented by the desired date format.

    New this week

    • :warning: MSRV increased from 1.53.0 to 1.54.0 per our 3-behind MSRV policy.
    • Conversions from aws_smithy_types::DateTime to OffsetDateTime from the time crate are now available from the aws-smithy-types-convert crate. (smithy-rs#849)
    • Fixed links to Usage Examples (smithy-rs#862, @floric)
    • Added missing features to user agent formatting, and made it possible to configure an app name for the user agent via service config. (smithy-rs#865)
    • :bug: Relaxed profile name validation to allow @ and other characters (smithy-rs#861, aws-sdk-rust#270)
    • :bug: Fixed signing problem with S3 Control (smithy-rs#858, aws-sdk-rust#291)
    • :tada: Timeouts for requests are now configurable. You can set a timeout for each individual request attempt or for all attempts made for a request. (smithy-rs#831)
      • SdkError now includes a variant TimeoutError for when a request times out (smithy-rs#885)
    • Improve docs on aws-smithy-client (smithy-rs#855)
    • Fix http-body dependency version (smithy-rs#883, aws-sdk-rust#305)

    Contributions

    Thank you for your contributions! :heart:

    • @floric (smithy-rs#862)
    Source code(tar.gz)
    Source code(zip)
  • v0.0.25-alpha(Nov 11, 2021)

    No changes since last release except for version bumping since older versions of the AWS SDK were failing to compile with the 0.27.0-alpha.2 version chosen for some of the supporting crates.

    Source code(tar.gz)
    Source code(zip)
  • v0.0.24-alpha(Nov 9, 2021)

    Breaking Changes

    • Members named builder on model structs were renamed to builder_value so that their accessors don't conflict with the existing builder() methods (smithy-rs#842)

    New this week

    • Fix epoch seconds date-time parsing bug in aws-smithy-types (smithy-rs#834)
    • Omit trailing zeros from fraction when formatting HTTP dates in aws-smithy-types (smithy-rs#834)
    • Moved examples into repository root (aws-sdk-rust#181, smithy-rs#843)
    • Model structs now have accessor methods for their members. We recommend updating code to use accessors instead of public fields. A future release will deprecate the public fields before they are made private. (smithy-rs#842)
    • :bug: Fix bug that caused signing to fail for requests where the body length was <=9. (smithy-rs#845)
    Source code(tar.gz)
    Source code(zip)
  • v0.0.23-alpha(Nov 5, 2021)

    To upgrade to the new version of the SDK, update your version to 0.0.23-alpha:

    [dependencies]
    aws-sdk-s3 = "0.0.23-alpha"
    

    New this week

    • 🎉 The SDK is available on crates.io! This also means that generated docs are now searchable and hosted on https://docs.rs.
    • :tada: Add support for AWS Glacier (smithy-rs#801)
    • :tada: Add support for AWS Panorama
    • :bug: Fix native-tls feature in aws-config (aws-sdk-rust#265, smithy-rs#803)
    • 📖 Add example to aws-sig-auth for generating an IAM Token for RDS (smithy-rs#811, aws-sdk-rust#147)
    • :bug: hyper::Error(IncompleteMessage) will now be retried (smithy-rs#815)
    • :bug: Fix generated docs on unions like dynamodb::AttributeValue. (smithy-rs#826)

    Breaking Changes

    • <operation>.make_operation(&config) is now an async function for all operations. Code should be updated to call .await. This will only impact users using the low-level API. (smithy-rs#797)
    • :bug: S3 request metadata signing now correctly trims headers fixing problems like this (smithy-rs#761)
    Source code(tar.gz)
    Source code(zip)
  • v0.0.22-alpha(Oct 20, 2021)

    Breaking Changes

    • CredentialsError variants became non-exhaustive & now have struct bodies. This makes them impossible to construct directly outside of the aws_types crate. In order to construct credentials errors, new methods have been added for each variant. Instead of CredentialsError::Unhandled(...), you should instead use CredentialsError::unhandled. Matching methods exist for all variants. If you match on specific variants, you will also need to update your code to include ... (#781)
    • The default credentials chain now returns CredentialsError::CredentialsNotLoaded instead of ProviderError when no credentials providers are configured.
    • :warning: All Smithy runtime crates have been renamed to have an aws- prefix. This may require code changes:
      • Cargo.toml changes:
        • smithy-async -> aws-smithy-async
        • smithy-client -> aws-smithy-client
        • smithy-eventstream -> aws-smithy-eventstream
        • smithy-http -> aws-smithy-http
        • smithy-http-tower -> aws-smithy-http-tower
        • smithy-json -> aws-smithy-json
        • smithy-protocol-test -> aws-smithy-protocol-test
        • smithy-query -> aws-smithy-query
        • smithy-types -> aws-smithy-types
        • smithy-xml -> aws-smithy-xml
      • Rust use statement changes:
        • smithy_async -> aws_smithy_async
        • smithy_client -> aws_smithy_client
        • smithy_eventstream -> aws_smithy_eventstream
        • smithy_http -> aws_smithy_http
        • smithy_http_tower -> aws_smithy_http_tower
        • smithy_json -> aws_smithy_json
        • smithy_protocol_test -> aws_smithy_protocol_test
        • smithy_query -> aws_smithy_query
        • smithy_types -> aws_smithy_types
        • smithy_xml -> aws_smithy_xml

    New this week

    • Moved the contents of aws-auth into the aws-http runtime crate (smithy-rs#783)
    • Fix instances where docs were missing in generated services and add #[warn_missing_docs] (smithy-rs#779)
    • Add tracing output for resolved AWS endpoint (smithy-rs#784)
    • Update AWS service models (smithy-rs#790)
    • Add support for the following Glacier customizations:
      • Set the ApiVersion header (smithy-rs#138, #787)
    Source code(tar.gz)
    Source code(zip)
  • v0.0.21-alpha(Oct 18, 2021)

    v0.0.21-alpha (October 15th, 2021)

    New this week

    • Prepare crate manifests for publishing to crates.io (smithy-rs#755)
    • Add support for IAM Roles for tasks credential provider (smithy-rs#765, aws-sdk-rust#123)
    • All service crates now have generated README files (smithy-rs#766)
    • Update AWS service models (smithy-rs#772)
    • :tada: Add support for Amazon Managed Grafana (smithy-rs#772)
    • :tada: Make retry behavior configurable
      • With env vars AWS_MAX_ATTEMPTS and AWS_RETRY_MODE
      • With ~/.aws/config settings max_attempts and retry_mode
      • By calling the with_retry_config method on a Config and passing in a RetryConfig
      • Only the Standard retry mode is currently implemented. Adaptive retry mode will be implemented at a later date.
      • For more info, see the AWS Reference pages on configuring these settings:
    Source code(tar.gz)
    Source code(zip)
Owner
Amazon Web Services - Labs
AWS Labs
Amazon Web Services - Labs
Cookiecutter templates for Serverless applications using AWS SAM and the Rust programming language.

Cookiecutter SAM template for Lambda functions in Rust This is a Cookiecutter template to create a serverless application based on the Serverless Appl

AWS Samples 24 Nov 11, 2022
Rusoto is an AWS SDK for Rust

Rusoto is an AWS SDK for Rust You may be looking for: An overview of Rusoto AWS services supported by Rusoto API documentation Getting help with Rusot

null 2.6k Dec 5, 2022
Rust SDK wrapper for the Mystic Light SDK

mystic_light_sdk Rust SDK wrapper for the Mystic Light SDK Requirements Any MSI device with RGB support Only Windows 7+ Dragon Center or Msi Center in

null 4 May 3, 2022
Rust client for AWS Infinidash service.

AWS Infinidash - Fully featured Rust client Fully featured AWS Infinidash client for Rust applications. You can use the AWS Infinidash client to make

Rafael Carício 15 Feb 12, 2022
📦 🚀 a smooth-talking smuggler of Rust HTTP functions into AWS lambda

lando ?? maintenance mode ahead ?? As of this announcement AWS not officialy supports Rust through this project. As mentioned below this projects goal

Doug Tangren 68 Dec 7, 2021
Ref Arch: Serverless GraphQL in Rust on AWS

A Whole Hog Reference Architecture for an Apollo Federation-Ready, Serverless, Rust-Based GraphQL Microservice on AWS using Cloud Development Kit (CDK)

Michael Edelman 3 Jan 12, 2022
A Rust runtime for AWS Lambda

Rust Runtime for AWS Lambda This package makes it easy to run AWS Lambda Functions written in Rust. This workspace includes multiple crates: lambda-ru

Amazon Web Services - Labs 2.4k Nov 29, 2022
Remote Secret Editor for AWS Secret Manager

Barberousse - Remote Secrets Editor About Usage Options Printing Editing Copying RoadMap 1.0 1.1 Future About A project aimed to avoid downloading sec

Mohamed Zenadi 18 Sep 28, 2021
Easy switch between AWS Profiles and Regions

AWSP - CLI To Manage your AWS Profiles! AWSP provides an interactive terminal to interact with your AWS Profiles. The aim of this project is to make i

KubeOps Skills 13 Nov 10, 2022
Simple fake AWS Cognito User Pool API server for development.

Fakey Cognito ?? Homepage Simple fake AWS Cognito API server for development. ✅ Implemented features AdminXxx on User Pools API. Get Started # run wit

naokirin 4 Aug 30, 2022
Postgres proxy which allows tools that don't natively supports IAM auth to connect to AWS RDS instances.

rds-iamauth-proxy rds-proxy lets you make use of IAM-based authentication to AWS RDS instances from tools that don't natively support that method of a

Gold Fig Labs Inc. 10 Nov 7, 2022
A tool to run web applications on AWS Lambda without changing code.

AWS Lambda Adapter A tool to run web applications on AWS Lambda without changing code. How does it work? AWS Lambda Adapter supports AWS Lambda functi

AWS Samples 276 Dec 1, 2022
cargo-lambda a Cargo subcommand to help you work with AWS Lambda

cargo-lambda cargo-lambda is a Cargo subcommand to help you work with AWS Lambda. This subcommand compiles AWS Lambda functions natively and produces

David Calavera 160 Nov 30, 2022
cargo-lambda is a Cargo subcommand to help you work with AWS Lambda.

cargo-lambda cargo-lambda is a Cargo subcommand to help you work with AWS Lambda. The new subcommand creates a basic Rust package from a well defined

null 159 Nov 25, 2022
Managing schema for AWS Athena in GitOps-style

athena-rs Managing AWS Athena Schemas Installation $ cargo install --git https://github.com/duyet/athena-rs $ athena --help athena 0.1.0 Duyet <[email protected]

Duyet Le 3 Sep 25, 2022
Nitrogen - a tool for deploying web services to AWS Nitro Enclaves

Nitrogen CLI Nitrogen is a tool for deploying web services to AWS Nitro Enclaves. Given a dockerfile and an ssh key, Nitrogen will spin up an EC2, con

Cape Privacy 54 Nov 18, 2022
Fegeya Gretea (aka green tea), new generation programming language.

Fegeya Gretea Gretea (aka green tea), new generation programming language. A taste of Gretea's syntax: import tea.green.fmt module hello { fn hel

Ferhat Geçdoğan 13 Sep 28, 2022
An experimental programming language for exploring first class iterators.

An experimental programming language for exploring first class iterators.

Miccah 4 Nov 23, 2021
A formal, politely verbose programming language for building next-gen reliable applications

vfpl Pronounced "Veepl", the f is silent A politely verbose programming language for building next-gen reliable applications Syntax please initialize

VFPL 4 Jun 27, 2022