-
Notifications
You must be signed in to change notification settings - Fork 13
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
[FYST-1089] refactor twilio service #4944
base: main
Are you sure you want to change the base?
Conversation
Heroku app: https://gyr-review-app-4944-3d8f2d5ce12a.herokuapp.com/ |
…ve space for a twilio account per service type; update the MultiTenantService to know about twilio.
…sier review. if folks like the direction, i'll turn it into a proper refactor
dbee352
to
505cdfc
Compare
…n start fixing tests and callsites
…wise; specs to support
…e only callsite of the #valid_request? method
…re's not tests for this, which worries me, but we shouldn't ever need to run this again, right? ...right?
…tes relevant specs
…'t look like there are any related tests. that's probably fine, right
… am _guessing_ that ctc is the right tenant for this use case.
…job. specs are green because of the use of a clever mock (MockTwilio). neat.
…pdated TwilioService api. wee bit of code formatting cleanup too
…e the updated TwilioService api
…actored (and improved upon) in the main TwilioService
@@ -12,104 +13,101 @@ class TwilioService | |||
delivered | |||
undelivered | |||
failed | |||
].freeze | |||
).unshift(nil) # why do we need nil in this list, and why must it be first? |
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.
[DUST] i assume you're planning to remove this comment before merging? would prefer not to leave stuff like this around the codebase
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.
yes! for sure. i literally don't know the answer but would like to. 😅
filename: "a_real_image.jpg", | ||
body: "image body" | ||
}) | ||
allow(TwilioService).to receive(:fetch_attachment).with(pdf_url).and_return({ | ||
allow(@twilio_service).to receive(:fetch_attachment).with(pdf_url).and_return({ |
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'm unfamiliar with using instance variables in rspec specs—typically we'd put something like this in a let
block (not to say it's better, just that it's the practice). happy to discuss!
@@ -34,7 +34,7 @@ def self.send_message(message_name, batch_size=nil, after: nil) | |||
end | |||
|
|||
if signup.phone_number.present? | |||
TwilioService.send_text_message(to: signup.phone_number, body: message.sms_body) | |||
TwilioService.new(:ctc).send_text_message(to: signup.phone_number, body: message.sms_body) |
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 is actually not just a CTC thing! see: https://www.getyourrefund.org/en/sign-up
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.
that makes me moderately unhappy. but it's kinda sorta ok as right now ctc and gyr seem to be sharing the same twilio setup.
@@ -4,7 +4,7 @@ class SendOutgoingTextMessageJob < ApplicationJob | |||
def perform(outgoing_text_message_id) | |||
outgoing_text_message = OutgoingTextMessage.find(outgoing_text_message_id) | |||
begin | |||
message = TwilioService.send_text_message( | |||
message = TwilioService.new.send_text_message( # TODO: set explicit service scope; is this job for :ctc or :gyr? |
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.
[DUST] again, would like to remove comments before merging
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.
absolutely. do you know if/how this job is aware of it's tenant service/environment?
just a general question about this PR: what was the thinking behind refactoring this from a singleton into a class that gets instantiated with a service type (as opposed to, say, passing the service type into related to that: do we want to consolidate the twilio subaccounts into just the main account? i feel like we talked about this on friday but wasn't sure how serious we are about it. this approach accounts for having different account info (account sid + auth token) per service type but if we just have the one maybe that would affect the implementation anyway, assuming we will discuss verbally just wanted to write down my thoughts before i forget them |
…eaching directly into the client (also updates specs)
…iated specs with what i hope is the final form of twilio ccount representation
I prefer an instantiated class for a couple of reasons:
re: consolidating accounts. Yes, that's a very real thing and this PR assumes that work is done. I think we'll end up with 2 accounts (down from 5)--one main account that'll house the FYST-related services/assets, and one subaccount that'll do the same for GYR (with CTC as a technically also there deprecated sidecar). Each account will have many messaging services--one per supported environment--with each messaging service having a specific sender pool and environment configuration. Hope this all makes sense and isn't too disrupting. Lemme know if you wanna talk through it more; happy to get on a call about any/all of it! |
Link to pivotal/JIRA issue
FYST-1089
Is PM acceptance required? (delete one)
Yes - don't merge until JIRA issue is accepted!
Reminder: merge main into this branch and get green tests before merging to main
What was done?
Updates credentials file structure
The structure below would appear in each environment's credentials file. This structure reflects a simplified Twilio organization that isn't reflective of the current setup; restructuring the Twilio services and setup is a blocking dependency of this refactor.
How to test?