Repository navigation
Explicitly ignore events listed in #609 - #639
Merged
Merged
Conversation
begedin
force-pushed
the
634-explicitly-ignore-events
branch
3 times, most recently
from
January 15, 2017 23:24
c2169d5 to
484ae4b
Compare
Contributor
Author
|
Ready for review, I believe. There are 2 commits, but I do not think we should squash, since each of them is a distinct change. |
begedin
commented
Jan 15, 2017
| @@ -1,5 +1,5 @@ | |||
| defmodule CodeCorps.StripeService.Events.AccountUpdated do | |||
| def handle(%{"data" => %{"object" => %{"id" => id_from_stripe}}}) do | |||
| def handle(%{data: %{object: %{id: id_from_stripe}}}) do | |||
Contributor
Author
There was a problem hiding this comment.
One of the changes involved passing in the fetched Stripe.Event into the handlers, instead of the raw json.
begedin
force-pushed
the
634-explicitly-ignore-events
branch
from
January 15, 2017 23:27
484ae4b to
4124d53
Compare
joshsmith
approved these changes
Jan 15, 2017
| end | ||
|
|
||
| @spec get_reason(String.t) :: String.t | ||
| defp get_reason("application_fee.created"), do: "Event provides no useful information." |
Contributor
There was a problem hiding this comment.
Would rewrite to:
"We don't make use of the application fee."
| defp get_reason("customer.source.created"), do: "Cards are only created from the client. No need to handle" | ||
| defp get_reason("customer.subscription.created"), do: "Subscriptions are only created from the client. No need to handle." | ||
| defp get_reason("invoice.created"), do: "Event provides no useful information." | ||
| defp get_reason("plan.created"), do: "Plans are only created from the client. No need to handle." |
Contributor
There was a problem hiding this comment.
Would remove "No need to handle." everywhere.
| defp get_reason("customer.created"), do: "Customers are only created from the client. No need to handle." | ||
| defp get_reason("customer.source.created"), do: "Cards are only created from the client. No need to handle" | ||
| defp get_reason("customer.subscription.created"), do: "Subscriptions are only created from the client. No need to handle." | ||
| defp get_reason("invoice.created"), do: "Event provides no useful information." |
Contributor
There was a problem hiding this comment.
Would rewrite to:
"We prefer to handle other lifecycle events for invoices, like payment_succeeded."
joshsmith
force-pushed
the
634-explicitly-ignore-events
branch
2 times, most recently
from
January 15, 2017 23:47
0cef9b5 to
7711fe6
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What's in this PR?
This PR first reorganizes the
WebhookProcessormodule so that the environment/livemode filtering goes into its own module.Then it separates
process_asyncandprocessso thatprocess can be more easily tested.Then it extracts the event handling logic from
WebhookProcessorintoEventHandler, so this can be further and more easily tested, while relying less onStripeTesting(though there is still some reliance.Lastly, it hooks into
EventHandlerwith a newIgnoredEventHandlermodule, which is in charge of explicitly ignoring some Stripe event types.The term explicitly igoring here means
event.statuswill be set to "ignored"event.ignored_reasonfield will be set to an informative message based on event type.References
Fixes #634