-
Notifications
You must be signed in to change notification settings - Fork 119
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: logins of already-existing users result in the user's customer contact info being updated (e.g. in stripe.com dashboard) #2103
Conversation
… error when extra props are passed as part of contact
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks solid to me and nicely tested.
Out of curiosity, is it actually possible for an email-registered user to change their email but keep the same issuer? I noticed you have a test for it, but wasn't aware that was a thing 😄 Either way, the test is a good idea and makes sense to include.
@yusefnapora tysm!
I haven't seen in happen. But it's kind of an implementation detail of how magic.link works, which I don't really understand! :P That scenario might happen if you log in with github, but your github-profile email changed since last login. magic.link might give same issuer (which is our pk in the user table) but the updated email? idk but I wouldn't be surprised if it's possible. It seemed like reasonable business logic to encode as a regression test. and if we learn otherwise it's hopefully easy to adjust it |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this all looks great to me! see my comment re: Stripe's "test mode" API and investigating a version of the CustomerService that uses it for end-to-end testing - if you think that's worth digging into I'd be happy to spend some time today/next week spiking this out
@@ -454,4 +454,174 @@ describe('userLoginPost', function () { | |||
assert.ok(gotSubscription, 'gotSubscription is truthy') | |||
assert.equal(gotSubscription.storage?.price, storagePriceNames.free) | |||
}) | |||
it('login to email-originating user updates customer contact', async function () { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not totally clear to me what "email-originating user" means here - is this just any user who signed up with an email?
} | ||
await customers.updateContact(customer.id, contactUpdate2) | ||
const contact2 = await customers.getContact(customer.id) | ||
assert.deepEqual(contact2, contactUpdate2, 'getContact returns same contact as the udpate') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
very minor tpyo here ('udpate' -> 'update')
if (hasOwnProperty(error, 'code')) { | ||
switch (error.code) { | ||
case 'resource_missing': | ||
return new CustomerNotFound('customer not found') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have complicated feelings about errors as flow control so don't disagree with this pattern, but curious if there's a deeper philosophical reason we're returning this CustomerNotFound
rather than throwing it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@travis in short, it's for type safety of the 'error' result value types. afaik tsc won't typecheck the type of what gets throw
n. It's definitely unusual compared to the whole world of js, but I like the pattern of having 'result types' that are union of both 'happy path' and specific error tyeps. iirc @yusefnapora seemed fine with it too in earlier review. When I used it in here originally I was a bit inspired by how @Gozala was using them in ucanto. https://github.com/web3-storage/ucanto/blob/b752b398950120d6121badcdbb639f4dc9ce8794/packages/interface/src/lib.ts#L267
/** | ||
* Create a mock stripe sdk instance that can be used with the StripeCustomersService | ||
* @returns {StripeComForCustomersService} | ||
*/ | ||
export function createMockStripeForCustomersService () { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this looks good and makes sense, AND is starting to get to the level of complexity where it seems worth investigating whether we can use Stripe's API in "test mode" (https://stripe.com/docs/keys#test-live-modes) to get some end-to-end testing into place.
I dug around in the Stripe API docs enough to convince myself it would probably be worth investigating this but not enough to be sure they actually implement this particular API functionality in test mode - I would definitely be down to do a quick spike on this if you think it makes sense to keep digging into this!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
adding - if I do find this is possible, I'd want to add it to a test suite that primarily gets run during CI so we can still run the existing tests offline/on a plane. it seems like test:e2e
in the top level package.json
might be a good place for this - seems like I'd need to add a similar test:e2e
script to the api
project, does that sound right?
🤖 I have created a release *beep* *boop* --- ## [7.12.0](api-v7.11.3...api-v7.12.0) (2022-11-11) ### Features * logins of already-existing users result in the user's customer contact info being updated (e.g. in stripe.com dashboard) ([#2103](#2103)) ([a365b4c](a365b4c)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Motivation:
Todo
Challenges
How to Test on staging/production