aws-smithy-json

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:

• 🎉 (smithy-rs#1411, smithy-rs#1167) Upgrade to Gradle 7. This change is not a breaking change, however, users of smithy-rs will need to switch to JDK 17
• 🐛 (smithy-rs#1505, @kiiadi) Fix issue with codegen on Windows where module names were incorrectly determined from filenames

Contributors Thank you for your contributions! ❤

• @kiiadi (smithy-rs#1505) <!-- Do not manually edit this file, use update-changelogs -->

New this release:

• (smithy-rs#1460) Fix a potential bug with ByteStream's implementation of futures_core::stream::Stream and add helpful error messages for users on 32-bit systems that try to stream HTTP bodies larger than 4.29Gb.
• 🐛 (smithy-rs#1427, smithy-rs#1465, smithy-rs#1459) Fix RustWriter bugs for rustTemplate and docs utility methods
• 🐛 (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.

New this release:

• 🎉 (smithy-rs#1381, @alonlud) Add ability to sign a request with all headers, or to change which headers are excluded from signing
• 🎉 (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#1404, @petrosagg) Add ability to specify a different rust crate name than the one derived from the package name
• (smithy-rs#1404, @petrosagg) Switch to RustCrypto's implementation of MD5.

Contributors Thank you for your contributions! ❤

• @alonlud (smithy-rs#1381)
• @petrosagg (smithy-rs#1404)

Breaking Changes:

• ⚠🎉 (aws-sdk-rust#494, aws-sdk-rust#519) The aws_smithy_http::byte_stream::bytestream_util::FsBuilder has been updated to allow for easier creation of multi-part requests.

  • FsBuilder::offset is a new method allowing users to specify an offset to start reading a file from.
  • FsBuilder::file_size has been reworked into FsBuilder::length and is now used to specify the amount of data to read.

  With these two methods, it's now simple to create a ByteStream that will read a single "chunk" of a file. The example below demonstrates how you could divide a single File into consecutive chunks to create multiple ByteStreams.

  let example_file_path = Path::new("/example.txt");
  let example_file_size = tokio::fs::metadata(&example_file_path).await.unwrap().len();
  let chunks = 6;
  let chunk_size = file_size / chunks;
  let mut byte_streams = Vec::new();
  
  for i in 0..chunks {
      let length = if i == chunks - 1 {
          // If we're on the last chunk, the length to read might be less than a whole chunk.
          // We substract the size of all previous chunks from the total file size to get the
          // size of the final chunk.
          file_size - (i * chunk_size)
      } else {
          chunk_size
      };
  
      let byte_stream = ByteStream::read_from()
          .path(&file_path)
          .offset(i * chunk_size)
          .length(length)
          .build()
          .await?;
  
      byte_streams.push(byte_stream);
  }
  
  for chunk in byte_streams {
      // Make requests to a service
  }
  

New this release:

• (smithy-rs#1352) Log a debug event when a retry is going to be peformed
• (smithy-rs#1332, @82marbag) Update generated crates to Rust 2021

Contributors Thank you for your contributions! ❤

• @82marbag (smithy-rs#1332)

Breaking Changes:

• ⚠ (smithy-rs#1318) Bump MSRV from 1.56.1 to 1.58.1 per our "two versions behind" policy.

New this release:

• (smithy-rs#1307) Add new trait for HTTP body callbacks. This is the first step to enabling us to implement optional checksum verification of requests and responses.
• (smithy-rs#1330) Upgrade to Smithy 1.21.0

Breaking Changes:

• ⚠ (aws-sdk-rust#490) Update all runtime crates to edition 2021

New this release:

• (smithy-rs#1262, @liubin) Fix link to Developer Guide in crate's README.md
• (smithy-rs#1301, @benesch) Update urlencoding crate to v2.1.0

Contributors Thank you for your contributions! ❤

• @benesch (smithy-rs#1301)
• @liubin (smithy-rs#1262)

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_s3_sdk::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:

  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:

• (smithy-rs#1225) DynMiddleware is now cloneable
• (smithy-rs#1257) HTTP request property bag now contains list of desired HTTP versions to use when making requests. This list is not currently used but will be in an upcoming update.

Breaking Changes:

• ⚠ (smithy-rs#1197) aws_smithy_types::retry::RetryKind had its NotRetryable variant split into UnretryableFailure and Unnecessary. If you implement the ClassifyResponse, then successful responses need to return Unnecessary, and failures that shouldn't be retried need to return UnretryableFailure.
• ⚠ (smithy-rs#1209) aws_smithy_types::primitive::Encoder is now a struct rather than an enum, but its usage remains the same.
• ⚠ (smithy-rs#1217) ClientBuilder helpers rustls() and native_tls() now return DynConnector and use dynamic dispatch rather than returning their concrete connector type that would allow static dispatch. If static dispatch is desired, then manually construct a connector to give to the builder. For example, for rustls: builder.connector(Adapter::builder().build(aws_smithy_client::conns::https())) (where Adapter is in aws_smithy_client::hyper_ext).

New this release:

• 🐛 (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.