connec
Repos
33
Followers
22
Following
8

A CloudFormation CLI that won't make you cry.

0
0

A CloudFormation library offering richly typed higher-level APIs to perform long-running operations and await their termination or observe their progress.

0
0

Request-scoped sqlx transactions for axum

25
7

Events

Feature suggestion: ability to interactively disable deployment of selected resources

When developing a template, it may sometimes be necessary to delete a resource(s) in order to update the configuration (e.g. if using fixed names, or when migrating from an API Gateway w/ Target to explicitly configured stages). In these situations, what seems to be the only two recourses are:

  1. Delete the entire template and redeploy it. This is fine and straightforward but impacts many more resources than strictly necessary, which could be disruptive or at least slows down iteration.
  2. Selectively comment out the affected resources and anything that depends on them. Manually commenting in/out resources is tedious enough, but it's also fairly error-prone when dealing with resource dependencies.

This feature suggestion is to make option 2. more convenient. We can parse the template and resolve resource dependencies, then given some flag to apply-stack present a checklist to the user to interactively disable some resources. Disabling a resource would also disable any resources/outputs that depend on it. The disabled resources/outputs could then be filtered out of the template prior to deployment.

Created at 4 days ago
Using an SSO profile with multiple packageable properties leads to multiple authentication prompts

As titled.

Created at 4 days ago
connec delete branch fix-package-dir
Created at 1 week ago

fix: use relative path in zip entries

This fixes packaging directories with subdirectories, since we were previously using only the file name.

chore: fix new clippy lint

The original complaint was unnecesarily borrowing path for the call to std::fs::read_dir, which led to realising that scandir didn't need to take ownership.

Created at 1 week ago
pull request closed
Use relative path in zip entries
  • e55a6e6 fix: use relative path in zip entries

    This fixes packaging directories with subdirectories, since we were previously using only the file name.

  • 6d10963 chore: fix new clippy lint

    The original complaint was unnecesarily borrowing path for the call to std::fs::read_dir, which led to realising that scandir didn't need to take ownership.

Created at 1 week ago

fix: use relative path in zip entries

This fixes packaging directories with subdirectories, since we were previously using only the file name.

chore: fix new clippy lint

The original complaint was unnecesarily borrowing path for the call to std::fs::read_dir, which led to realising that scandir didn't need to take ownership.

Created at 1 week ago

chore: fix new clippy lint

The original complaint was unnecesarily borrowing path for the call to std::fs::read_dir, which led to realising that scandir didn't need to take ownership.

Created at 1 week ago
pull request opened
Use relative path in zip entries
  • e8eaa85 fix: use relative path in zip entries

    This fixes packaging directories with subdirectories, since we were previously using only the file name.

Created at 1 week ago
connec create branch fix-package-dir
Created at 1 week ago
issue comment
Use 422 Unprocessable Entity for form deserialization errors

Of course, sorry I didn't have to follow it through!

Created at 2 weeks ago
delete branch
connec delete branch form-unprocessable-entity
Created at 2 weeks ago
issue comment
Use 422 Unprocessable Entity for form deserialization errors

Ah, it looks like I spoke too soon with my assumption that the Form and Query extractors were fully separated. You can presently use the Form extractor with GET requests and it will read from the URL query instead: https://github.com/tokio-rs/axum/blob/211de92d24a0d6e1ffc0c76b75c26c53c7eb09d3/axum/src/extract/raw_form.rs#L47-L64

As such, with this change, a GET request with semantically invalid Form data in the URL would return a 422, which #1378 establishes is invalid.

I'm not sure what would be the preferred solution to this? Some options I can think of:

  1. Remove the special-casing for GET requests (and perhaps direct people to Query in the documentation?). This seems like it would be a breaking change though.

  2. Pipe through some information about the source of the form data, and use separate composite_rejection variants for semantically invalid queries vs. bodies. Adding a separate variant would not be breaking, but RawForm is a public type with public fields, so adding any more info to the struct would also be a breaking change.

  3. The FromRequest implementations of RawForm and Form could be fully decoupled (i.e. copy the RawForm body implementation into the Form implementation). This would functionally be a breaking change, but the documentation for Form currently suggests that only request bodies are processed, so it could be argued to be a bug fix 😅 https://github.com/tokio-rs/axum/blob/211de92d24a0d6e1ffc0c76b75c26c53c7eb09d3/axum/src/form.rs#L15-L21

Perhaps there are other options?

Created at 3 weeks ago
issue comment
Use 422 Unprocessable Entity for form deserialization errors

Sure, I was a bit lazy and left it out since nothing was presently testing it, but happy to add one. I'll have to sort it a little bit later though.

Created at 3 weeks ago
pull request opened
Use 422 Unprocessable Entity for form deserialization errors

Fixes #1680.

Motivation

Per #1680, we would prefer to use 422 Unprocessable Entity responses for non-syntactic deserialization errors from the Form extractor. This is now trivial since the Form and Query rejection types were separated in #1496.

Solution

  • Update the status for axum::extract::rejection::FailedToDeserializeForm from BAD_REQUEST to UNPROCESSABLE_ENTITY.
  • The same change has been applied to axum_extra::extract::FormRejection::FailedToDeserializeForm for consistency.
Created at 3 weeks ago
create branch
connec create branch form-unprocessable-entity
Created at 3 weeks ago
Created at 3 weeks ago
opened issue
`Form` extractor should return 422 Unprocessable Entity for deserialization errors
  • [x] I have looked for existing issues (including closed) about this

Feature Request

Motivation

I noticed this when upgrading a project from axum 0.5 to 0.6, which led to some failing tests of invalid form data: deserialization errors from the Form extractor now convert into 400 Bad Request responses, when previously they were 422 Unprocessable Entity responses. Per the semantics discussed in #1378 it seems like 422 Unprocessable Entity would be the more appropriate response for syntactically valid form data that could not be deserialized.

Proposal

From doing some digging around, it looks like this change occurred to fix #1378. At that time, the rejection for a Form deserialization error was also FailedToDeserializeQueryString: https://github.com/tokio-rs/axum/blob/74105fc7904411df27f116c958f9266007f4650b/axum/src/extract/rejection.rs#L141-L151

Later, in #1496, Form gets a dedicated FailedToDeserializeForm variant: https://github.com/tokio-rs/axum/blob/351df649ab05fb30c382167b2158828a4f48e4a3/axum/src/extract/rejection.rs#L99-L109

However, this rejection is still set to return a 400 Bad Request: https://github.com/tokio-rs/axum/blob/211de92d24a0d6e1ffc0c76b75c26c53c7eb09d3/axum/src/extract/rejection.rs#L73-L79

Since the Form and Query extractors now have dedicated rejection types, it seems we could simply update the status for FailedToDeserializeForm to UNPROCESSABLE_ENTITY without disturbing the original fix in #1378. I'd be happy to make that PR if it's desirable and I'm not missing anything. This would be a breaking change (assuming the rejection statuses are covered by the versioning policy).

Created at 3 weeks ago
closed issue
Unexpected panic when there are no changes to apply
thread 'main' panicked at 'Stack without change_set_id', cloudformatious-0.1.2/src/apply_stack.rs:434:48
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Assumed to be related to there being no changes. It's not clear why this does seem to work in some cases, e.g. https://github.com/connec/cloudformatious/blob/82fdf778e249611a8ab9f8703b95df350e7819dd/tests/it/apply_stack.rs#L211-L239.

Created at 1 month ago

fix: avoid panicking if change_set_id isn't available on stack

For reasons unknown, CloudFormation stacks lose their change_set_id if a no-op change set is created against a stack in the UPDATE_ROLLBACK_COMPLETE state. This was causing a panic, since we assumed the field would always be set. This assumption was based on the fact that we must have successfully created a change set before we would call describe_output (even if the change set reaches a failing terminal status, it would still have an ID). As a simple and direct fix, we now simply pass the change set ID along to describe_output.

This could technically be considered a breaking change, since it changes the reported change_set_id on no-op updates to stacks not in the UPDATE_ROLLBACK_COMPLETE state. However, we could argue that the original intent was for the ApplyStackOutput to include the ID of the change set that was created for the operation, and that the previous behaviour for no-up updates was a bug (and indeed we argue this, and so don't consider this a breaking change...).

Fixes #11.

fix: parameterise region in serverless transform permission

This allows the tests to operate in non-eu-west-2 regions.

Created at 1 month ago
delete branch
connec delete branch apply-rollback-complete-bug
Created at 1 month ago
pull request closed
Fix `UPDATE_ROLLBACK_COMPLETE` bug
  • 19eaacf fix: avoid panicking if change_set_id isn't available on stack

    For reasons unknown, CloudFormation stacks lose their change_set_id if a no-op change set is created against a stack in the UPDATE_ROLLBACK_COMPLETE state. This was causing a panic, since we assumed the field would always be set. This assumption was based on the fact that we must have successfully created a change set before we would call describe_output (even if the change set reaches a failing terminal status, it would still have an ID). As a simple and direct fix, we now simply pass the change set ID along to describe_output.

    This could technically be considered a breaking change, since it changes the reported change_set_id on no-op updates to stacks not in the UPDATE_ROLLBACK_COMPLETE state. However, we could argue that the original intent was for the ApplyStackOutput to include the ID of the change set that was created for the operation, and that the previous behaviour for no-up updates was a bug (and indeed we argue this, and so don't consider this a breaking change...).

    Fixes #11.

  • a1b2f06 fix: parameterise region in serverless transform permission

    This allows the tests to operate in non-eu-west-2 regions.

Created at 1 month ago
pull request opened
Fix `UPDATE_ROLLBACK_COMPLETE` bug
  • 19eaacf fix: avoid panicking if change_set_id isn't available on stack

    For reasons unknown, CloudFormation stacks lose their change_set_id if a no-op change set is created against a stack in the UPDATE_ROLLBACK_COMPLETE state. This was causing a panic, since we assumed the field would always be set. This assumption was based on the fact that we must have successfully created a change set before we would call describe_output (even if the change set reaches a failing terminal status, it would still have an ID). As a simple and direct fix, we now simply pass the change set ID along to describe_output.

    This could technically be considered a breaking change, since it changes the reported change_set_id on no-op updates to stacks not in the UPDATE_ROLLBACK_COMPLETE state. However, we could argue that the original intent was for the ApplyStackOutput to include the ID of the change set that was created for the operation, and that the previous behaviour for no-up updates was a bug (and indeed we argue this, and so don't consider this a breaking change...).

    Fixes #11.

  • a1b2f06 fix: parameterise region in serverless transform permission

    This allows the tests to operate in non-eu-west-2 regions.

Created at 1 month ago

fix: avoid panicking if change_set_id isn't available on stack

For reasons unknown, CloudFormation stacks lose their change_set_id if a no-op change set is created against a stack in the UPDATE_ROLLBACK_COMPLETE state. This was causing a panic, since we assumed the field would always be set. This assumption was based on the fact that we must have successfully created a change set before we would call describe_output (even if the change set reaches a failing terminal status, it would still have an ID). As a simple and direct fix, we now simply pass the change set ID along to describe_output.

This could technically be considered a breaking change, since it changes the reported change_set_id on no-op updates to stacks not in the UPDATE_ROLLBACK_COMPLETE state. However, we could argue that the original intent was for the ApplyStackOutput to include the ID of the change set that was created for the operation, and that the previous behaviour for no-up updates was a bug (and indeed we argue this, and so don't consider this a breaking change...).

Fixes #11.

fix: parameterise region in serverless transform permission

This allows the tests to operate in non-eu-west-2 regions.

Created at 1 month ago
create branch
connec create branch apply-rollback-complete-bug
Created at 1 month ago
connec create tag 0.4.0
Created at 1 month ago

chore: upgrade cloudformatious

This required an update to the ApplyStackInput struct.

feat: implement recovery from ROLLBACK_COMPLETE

This adds general "recovery" machinery to the apply_stack command, and a specific implementation for ROLLBACK_COMPLETE (by deleting the stack before re-running apply_stack).

chore: fix clippy lint

chore: bump version

Created at 1 month ago
connec delete branch recover
Created at 1 month ago
pull request closed
`ROLLBACK_COMPLETE` recovery
  • a0fbd12 chore: upgrade cloudformatious

    This required an update to the ApplyStackInput struct.

  • a64ec45 feat: implement recovery from ROLLBACK_COMPLETE

    This adds general "recovery" machinery to the apply_stack command, and a specific implementation for ROLLBACK_COMPLETE (by deleting the stack before re-running apply_stack).

  • 1fa095f chore: fix clippy lint

  • fde3d0c chore: bump version

Created at 1 month ago
pull request opened
`ROLLBACK_COMPLETE` recovery
  • a0fbd12 chore: upgrade cloudformatious

    This required an update to the ApplyStackInput struct.

  • a64ec45 feat: implement recovery from ROLLBACK_COMPLETE

    This adds general "recovery" machinery to the apply_stack command, and a specific implementation for ROLLBACK_COMPLETE (by deleting the stack before re-running apply_stack).

  • 1fa095f chore: fix clippy lint

  • fde3d0c chore: bump version

Created at 1 month ago