Skip to content
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

Draft
wants to merge 22 commits into
base: main
Choose a base branch
from

Conversation

jnf
Copy link
Contributor

@jnf jnf commented Nov 1, 2024

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.

twilio:
  voice_phone_number: <i think there's just the one>
  gyr:
    account_sid: <value>
    auth_token: <value>
    messaging_service_id: <value>
  statefile:
    account_sid: <value>
    auth_token: <value>
    messaging_service_id: <value>

How to test?

  • Describe the testing approach taken to verify the changes, including:
    • Unit/integration/manual tests
    • Test data used
  • Specify any relevant testing environments used (e.g., development, staging, demo, Heroku).
  • Risk Assessment
    • Risks or side effects associated with the changes and how they were mitigated.
    • Highlight areas that may need extra attention during code review or testing.
    • Paste SQL queries or output where relevant

@jnf jnf added the wip denotes a work in progress that isn't ready for formal review label Nov 1, 2024
Copy link

github-actions bot commented Nov 1, 2024

Heroku app: https://gyr-review-app-4944-3d8f2d5ce12a.herokuapp.com/
View logs: heroku logs --app gyr-review-app-4944 (optionally add --tail)

…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
@jnf jnf force-pushed the jnf/FYST-1089/refactor-twilio-service branch from dbee352 to 505cdfc Compare November 5, 2024 17:19
jnf added 17 commits November 5, 2024 10:02
…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?
…'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
…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?
Copy link
Contributor

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

Copy link
Contributor Author

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({
Copy link
Contributor

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)
Copy link
Contributor

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

Copy link
Contributor Author

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?
Copy link
Contributor

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

Copy link
Contributor Author

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?

@jenny-heath
Copy link
Contributor

jenny-heath commented Nov 6, 2024

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 send_text_message)? not opposed to this approach, just curious about the reasons for it.

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
@jnf
Copy link
Contributor Author

jnf commented Nov 7, 2024

I prefer an instantiated class for a couple of reasons:

  • send_text_message isn't the only method on TwilioService that needs info about which tenant service it's working with (client_metadata does too).
  • limits what caller's need to know about the internals. i like the general pattern of saying "i need to talk to twilio as fyst" and the TwilioService managing what that means behind the scenes (which is why i also replaced direct calls to Twilio::REST::Client with an instance of TwilioService

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wip denotes a work in progress that isn't ready for formal review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants