small functional improvements #662

robko23 · 2025-01-22T16:45:31Z

Summary

Hi, first of all - amazing work what you've done on the next branch. The api is absolutely amazing, but it still has some rough edges.
I've done one integration on 0.40 and now I'm building another integration and I've decided to use the next branch, so that I can test its ergonomics and help to improve it.

I would consider this PR a draft for now, because I'm just starting with the integration and I probably will send more patches if something doesn't work or doesn't seem right.

For now this PR contains two small commits - everything is explained in detail in the commit message as to why I've done it, but here is a list of things I've done (I will be editing this list with the new patches as I create them):

export StripeRequest trait - allow .customize() to be used outside this crate
change Idempotency-Key to idempotency-key - caused panic on runtime

Checklist

ran cargo make fmt
using conventional commits to hightlight user-facing fixes and features

`.customize()` function was not accesible from outside of the crate because trait StripeRequest was not exported anywhere Signed-off-by: Robin Ilyk <contact@robko.cz>

mzeitlin11

Thanks for contributing this @robko23, there are definitely lots of improvements that can be made!

I know this is in draft, but I'd be happy to merge this with the added assert! either changed to an error or removed since the other 2 changes should be pretty uncontroversial improvements.

mzeitlin11 · 2025-01-23T01:37:14Z

async-stripe/src/hyper/client.rs

@@ -109,7 +109,9 @@ impl Client {
        let mut last_error = StripeError::ClientError("invalid strategy".into());

        if let Some(key) = strategy.get_key() {
-            req_builder = req_builder.header(HeaderName::from_static("Idempotency-Key"), key);
+            const HEADER_NAME: HeaderName = HeaderName::from_static("idempotency-key");


Wow, that's a bad panic! Think this must've happened because the old usage of http-types instead of hyper/http supported this, and there must be no test coverage of idempotency key usage

mzeitlin11 · 2025-01-23T01:41:15Z

async-stripe/src/hyper/client.rs

@@ -109,7 +109,9 @@ impl Client {
        let mut last_error = StripeError::ClientError("invalid strategy".into());

        if let Some(key) = strategy.get_key() {
-            req_builder = req_builder.header(HeaderName::from_static("Idempotency-Key"), key);
+            const HEADER_NAME: HeaderName = HeaderName::from_static("idempotency-key");
+            assert!(!key.is_empty(), "idempotency key is empty");


Probably would be better to return an error here, could add a variant to StripeError. Even better would be to validate on construction of RequestStrategy, but that's not currently possible without hiding more of the internal representation there.

yeah, I put that assertion here because I wanted to narrow down the out of bound index and then I left it there because it seemed a good sanity check.
However I also think that having a proper error would be better, so I created a commit that adds a newtype for the idempotency key. It is basically a string that cannot be empty or longer than 255 chars. It has its own error, because I think its mostly isolated from the rest of the logic. Having it mostly transparent struct also doesn't hide any implementation and representation

idempotency key cannot be empty and cannot be longer than 255 characters and having asserts before their usage is not the best error handling strategy. having it in a newtype guarantees that every use of this key is valid and no assert or runtime panic is needed. Refs: arlyon#662 (comment) Refs: https://docs.stripe.com/api/idempotent_requests Signed-off-by: Robin Ilyk <contact@robko.cz>

robko23 · 2025-01-23T08:00:28Z

I've removed the assert and if you want to I can mark it as ready and you can merge it, but there will be more small changes from me as I use it more. I didn't want to overwhelm you with these one line PRs so my idea was to pack it in a single PR with many small commits. But if you don't mind this, I can break it down to more PRs

idempotency key cannot be empty and cannot be longer than 255 characters and having asserts before their usage is not the best error handling strategy. having it in a newtype guarantees that every use of this key is valid and no assert or runtime panic is needed. Refs: arlyon#662 (comment) Refs: https://docs.stripe.com/api/idempotent_requests Signed-off-by: Robin Ilyk <contact@robko.cz>

mzeitlin11 · 2025-02-09T02:22:55Z

Sorry for the delay here @robko23! I think the newtype approach is the right one generally, and I think that commit will be useful at a later point, but I'd imagine there will be more rounds of iteration on RequestStrategy going forward, so would like to hold off on breaking changes there since I think larger changes will come and don't want to have users testing out the next branch need to migrate their code too much.

We can also make an issue to start tracking / discussing what the most useful form of RequestStrategy might be given the new structure of having custom clients in the next branch.

I'd be happy to merge if you don't mind just reverting the RequestStrategy changes and the original assert, so that this just fixes the bug.

robko23 · 2025-02-09T07:39:49Z

Okay, so I cherry picked the commit with the newtype and I will create a new pull request with it. Then I removed this from this branch.

Then I changed the commit with the assert and removed it, but I still kept the const HEADER_NAME

idempotency key cannot be empty and cannot be longer than 255 characters and having asserts before their usage is not the best error handling strategy. having it in a newtype guarantees that every use of this key is valid and no assert or runtime panic is needed. Refs: arlyon#662 (comment) Refs: arlyon#662 (comment) Refs: https://docs.stripe.com/api/idempotent_requests Signed-off-by: Robin Ilyk <contact@robko.cz>

mzeitlin11

Thanks @robko23! CI failure should be unrelated, I have a fix in #660, which I will pull out separately.

mzeitlin11 · 2025-02-09T18:02:12Z

Ok, sorry for the annoyance, but CI should be good now, so if you can rebase I'll merge it!

arlyon · 2025-02-19T15:07:14Z

Hey thanks for this @robko23 ! I have been MIA for a little bit (was very ill for a couple of months the end of last year but I am back on form). @mzeitlin11 seems to be carrying the torch just fine in the mean time but I will stamp anyways.

EDIT: have updated the branch via a merge commit, will merge the PR if everything is green

arlyon · 2025-02-19T16:18:23Z

Seems like there is a genuine clippy lint here. Feel free to @ either myself or Matthew when this is addressed

http crate does not allow uppercase characters in header name and it was causing crashes when hitting thing branch with error "index out of bounds." The error should happen at compile time, but for some reason the HeaderName::from_static was executed at runtime, so this commit forces it to be executed at compile time by extracing it into the const. Signed-off-by: Robin Ilyk <contact@robko.cz>

robko23 · 2025-02-20T07:28:31Z

hi @arlyon! Thanks for the response and I hope your health will be better in the future.

About the clippy lint, I have decided to ignore (#[allow]) it since it seems like it is false positive.
It took me a while to trigger the lint on my machine and I figured out you have older version of rustc on the CI. You are using 1.75.0, I have 1.84.1 and it does not trigger there.
The reason why it gets triggered on the older version is that HeaderName uses bytes::Bytes and that uses AtomicPtr which triggers the lint.
bytes::Bytes is by default ignored by the clippy lint and for some reason clippy doesn't figure out this relationship and triggers the lint.

See this, this and this for more information

idempotency key cannot be empty and cannot be longer than 255 characters and having asserts before their usage is not the best error handling strategy. having it in a newtype guarantees that every use of this key is valid and no assert or runtime panic is needed. Refs: arlyon#662 (comment) Refs: arlyon#662 (comment) Refs: https://docs.stripe.com/api/idempotent_requests Signed-off-by: Robin Ilyk <contact@robko.cz>

kkudryaev · 2025-03-10T22:37:18Z

Hi! Thank you for your thorough work. Could you please merge this as soon as possible? I need to use the idempotent request strategy. Thanks!

mzeitlin11 · 2025-03-16T17:39:35Z

Sorry for the delay here, just running the CI now!

mzeitlin11 · 2025-03-16T20:46:49Z

I can look into fixing the new CI failures sometime next weekend, but hopefully just bumping MSRV is sufficient, and that should be fine since it's the next branch

augustoccesar · 2025-03-17T10:40:03Z

~~We can bump the MSRV, but these should also fix the CI:~~
~~- #672~~
~~- #673~~

Ignore this, I missed that this was on next 😅

mzeitlin11 · 2025-03-17T13:50:38Z

We can bump the MSRV, but these should also fix the CI:

chore: bump upload-artifact to v4 #672

fix: pin native-tls to <= 0.2.13 #673

Pinning native-tls works too but just noting this is a PR to the next branch, so CI looks different and there is no upload-artifact.

augustoccesar · 2025-03-17T17:59:04Z

We can bump the MSRV, but these should also fix the CI:

chore: bump upload-artifact to v4 #672

fix: pin native-tls to <= 0.2.13 #673

Pinning native-tls works too but just noting this is a PR to the next branch, so CI looks different and there is no upload-artifact.

Oh, sorry. I missed that this was on next 😅 Disregard my comment!

arlyon · 2025-03-18T14:24:15Z

The rust project have reversed their recommendations not to commit the Cargo.lock file so we may consider committing that to make CI less flaky. In the mean time I have bumped the MSRV

arlyon · 2025-03-18T14:33:53Z

Done! TY

fix(async-stripe): export StripeRequest

3691044

`.customize()` function was not accesible from outside of the crate because trait StripeRequest was not exported anywhere Signed-off-by: Robin Ilyk <contact@robko.cz>

mzeitlin11 reviewed Jan 23, 2025

View reviewed changes

robko23 force-pushed the next branch from 2dea022 to f2c451c Compare January 23, 2025 08:23

robko23 force-pushed the next branch from f2c451c to 4ea4bba Compare February 9, 2025 07:39

robko23 marked this pull request as ready for review February 9, 2025 07:40

robko23 changed the title ~~DRAFT: small functional improvements~~ small functional improvements Feb 9, 2025

robko23 mentioned this pull request Feb 9, 2025

feat(async-stripe-core): Create newtype for idempotency key #668

Merged

mzeitlin11 approved these changes Feb 9, 2025

View reviewed changes

arlyon approved these changes Feb 19, 2025

View reviewed changes

robko23 and others added 2 commits February 20, 2025 08:15

Make sure CI pins rust version in all jobs

7f471ea

robko23 force-pushed the next branch from 06ea05f to 7f471ea Compare February 20, 2025 07:16

Merge branch 'next' into next

7b92505

arlyon merged commit 4348824 into arlyon:next Mar 18, 2025
15 checks passed

robko23 deleted the next branch March 18, 2025 14:38

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

small functional improvements #662

small functional improvements #662

robko23 commented Jan 22, 2025

mzeitlin11 left a comment

mzeitlin11 Jan 23, 2025

mzeitlin11 Jan 23, 2025

robko23 Jan 23, 2025

robko23 commented Jan 23, 2025

mzeitlin11 commented Feb 9, 2025

robko23 commented Feb 9, 2025

mzeitlin11 left a comment

mzeitlin11 commented Feb 9, 2025

arlyon commented Feb 19, 2025 •

edited

Loading

arlyon commented Feb 19, 2025

robko23 commented Feb 20, 2025

kkudryaev commented Mar 10, 2025

mzeitlin11 commented Mar 16, 2025

mzeitlin11 commented Mar 16, 2025

augustoccesar commented Mar 17, 2025 •

edited

Loading

mzeitlin11 commented Mar 17, 2025

augustoccesar commented Mar 17, 2025 •

edited

Loading

arlyon commented Mar 18, 2025 •

edited

Loading

arlyon commented Mar 18, 2025

small functional improvements #662

small functional improvements #662

Conversation

robko23 commented Jan 22, 2025

Summary

Checklist

mzeitlin11 left a comment

Choose a reason for hiding this comment

mzeitlin11 Jan 23, 2025

Choose a reason for hiding this comment

mzeitlin11 Jan 23, 2025

Choose a reason for hiding this comment

robko23 Jan 23, 2025

Choose a reason for hiding this comment

robko23 commented Jan 23, 2025

mzeitlin11 commented Feb 9, 2025

robko23 commented Feb 9, 2025

mzeitlin11 left a comment

Choose a reason for hiding this comment

mzeitlin11 commented Feb 9, 2025

arlyon commented Feb 19, 2025 • edited Loading

arlyon commented Feb 19, 2025

robko23 commented Feb 20, 2025

kkudryaev commented Mar 10, 2025

mzeitlin11 commented Mar 16, 2025

mzeitlin11 commented Mar 16, 2025

augustoccesar commented Mar 17, 2025 • edited Loading

mzeitlin11 commented Mar 17, 2025

augustoccesar commented Mar 17, 2025 • edited Loading

arlyon commented Mar 18, 2025 • edited Loading

arlyon commented Mar 18, 2025

arlyon commented Feb 19, 2025 •

edited

Loading

augustoccesar commented Mar 17, 2025 •

edited

Loading

augustoccesar commented Mar 17, 2025 •

edited

Loading

arlyon commented Mar 18, 2025 •

edited

Loading