* remove: need for operation type aliasing
rename: FluentClientGenerics.sendBounds params to be more accurate
update: FlexibleClientGenerics.sendBounds impl for readability
update: type of FluentClientGenerator input param `retryPolicyType` to be `Any` with a default of `RustType.Unit`
update: PaginatorGenerator to take retryPolicy as an input
chore: fix some spelling and grammar issues
remove: redundant `nextTokenEmpty` function from PaginatorGenerator
* Update CHANGELOG.next.toml
Co-authored-by: John DiSanti <jdisanti@amazon.com>
* add: `writable` property to RustType that returns the type as a Writable
add: test for RustType writable
add: `writable` property to RuntimeType that returns the type as a Writable
update: FluentClientGenerator to take a writable for retry
* format: run formatter
Co-authored-by: John DiSanti <jdisanti@amazon.com>
* Create the `codegen-core` module
* Move the `Version` class into `codegen-core`
* Rename `codegen` to `codegen-client`
* Rename `codegen-test` to `codegen-client-test`
* Move shared test models to common location
* Fix Smithy validation errors in `misc.smithy`
feature: customizable operations
update: CHANGELOG.next.toml
update: RFC0017
update: add IntelliJ idea folder to .gitignore
add: GenericsGenerator with tests and docs
add: rustTypeParameters helper fn with tests and docs
add: RetryPolicy optional arg to FluentClientGenerator
move: FluentClientGenerator into its own file
Crate publish used to be slow due to the verification step that `cargo`
would run, which was basically a full compile of the crate prior to
uploading it to crates.io. Now that the `publisher` tool passes
`--no-verify` to `cargo`, it publishes fast enough to get throttled.
This change completely removes the publishing parallelism, adds a fixed
time between publishing each crate, and increases the publish retry
backoff time.
* Remove `Default` implementation from `RetryConfig`
* Add use case integration tests
* Panic when retries/timeouts are enabled without a `sleep_impl`
* Combine the sleep, retry, and timeout customizations
* Add `sleep_impl` validation to the Smithy client builder
* Upgrade minimum Tokio version to 1.8.4
This addresses RUSTSEC-2021-0072 and RUSTSEC-2021-0124.
The SDK, runtime crates, and server are set to the minimum secure
version of Tokio to allow a larger range of versions to be used by
consumers of those libraries. The tools and the Python server are
both set to the latest Tokio version since they are not intended
to be consumed as a libraries.
* Upgrade `tracing-subscriber` to 0.3.15
* Upgrade `criterion` to 0.3.6
This addresses RUSTSEC-2021-0093 by upgrading `criterion`, which
upgrades `rayon`, which upgrades `crossbeam-deque`.
* Add protocol specific `FromRequest` and `FromParts`.
* Add `OperationShape` trait to model Smithy operations.
* Add `Handler` and `OperationService` traits.
* Add `Upgrade` `Service` and `UpgradeLayer` `Layer`.
* add: ability for certain operations to be exempt from XML body root checking
* add: XML body root checking exemption for com.amazonaws.s3#GetObjectAttributesOutput
* test: missing RuntimeConfig node should behave the same as `{}`
* missing RuntimeConfig node should behave the same as `{}`
* use `maybe` prefix for Optional type
Co-authored-by: John DiSanti <jdisanti@amazon.com>
The visitor was examining the inner contents of the entire re-exported
type, which, for a type that is re-exported within the same crate, is
the correct behavior. Its the wrong behavior when exporting types from
other crates, however, since it doesn't matter what is inside that
external type, and rustdoc doesn't include information about inner
pieces of the external type in the JSON output.
While the set of supported protocols and their implementation is
different among servers and clients, the logic to load a specific
protocol given a Smithy model is identical. This commit makes
`ServerProtocolLoader` inherit from `ProtocolLoader` so that said logic
can be reused among clients and servers.
* Fix bug in coroutine scheduling. Add ByteStream implementation and simplify Python symbol visitor.
* Bug in coroutine scheduling:
In the previous iteration, the runtime crate aws-smithy-http-server-python
was exposing the python application implementation as a struct, which
was wrapped by the codegenerated App to allow to dynamically building
the router.
This caused scheduling of coroutines (handlers prefixed with async def)
to block becuse we were passing the Python eventloop of the parent
process that was stored pre-fork().
This commit changes the runtime PyApp to become a trait, allowing us to
dynamically build the router post-fork() and with the right event loop.
This change also allowed us to remove a bunch of unnecessary Arc(s).
* Add ByteStream implementation
Implementation of a ByteStream type for Python that can be roughly used like this:
let b = await ByteStream.from_path("file.txt")
async for chunk in b:
print(chunk)
Implement futures_core::stream::Stream for Python ByteStream wrapper.
The BytesStream implementation in python can now use a sync Mutex from
parking_lot because we are now using pyo3_asyncio::tokio::local_future_into_py()
to read a chunk, which supports !Send futures.
This allows to simply forward the implementation of Stream (poll_next()
and size_hint()) directly to our inner SDK ByteStream.
* Simplify Python symbol visitor
Inherit from Symbol visitor and override just what is needed to swap Python complex
types.
Signed-off-by: Bigo <1781140+crisidev@users.noreply.github.com>
Currently, conversions from `aws_smithy_types::Number` into numeric Rust
types (`{i,u}{8, 16, 32, 64}` and `f{32, 64}`) are always lossy, because
they use the `as` Rust keyword to cast into the target type. This means
that clients and servers are accepting lossy data: for example, if an
operation is modeled to take in a 32-bit integer as input, and a client
incorrectly sends an integer number that does not fit in 32 bits, the
server will silently accept the truncated input. There are malformed
request protocol tests that verify that servers must reject these
requests.
This commit removes the lossy `to_*` methods on `Number` and instead
implements `TryFrom<$typ> for Number` for the target numeric type
`$typ`. These converters will attempt their best to perform the
conversion safely, and fail if it is lossy.
The code-generated JSON parsers will now fail with
`aws_smithy_json::deserialize::ErrorReason::InvalidNumber` if the number
in the JSON document cannot be converted into the modeled integer type
without losing precision. For floating point target types, lossy
conversions are still performed, via `Number::to_f32_lossy` and
`Number::to_f64_lossy`.
Zelda Hessler