search

twilio / twilio-ruby

A Ruby gem for communicating with the Twilio API and generating TwiML
MIT License
1.35k stars 463 forks source link

Extra Parameters in Call Update #699

Open jon-sully opened 6 months ago

jon-sully commented 6 months ago

Issue Summary

Extra parameters are being sent along in my Call Updates — in particular, StatusCallbackMethod, Method, and FallbackMethod are all being sent to Twilio with the values of "POST" even though I didn't specify them in my actual calls(id).update( ... ) call.

This wouldn't be a big deal except that I think by specifying the method for any of these endpoints, the actual URL stored for them gets reset. So my incoming calls, which had a Status Callback URL set by the TwiML App assigned to that phone number, were having their Status Callback URLs reset any time I used the Call Update API.

Steps to Reproduce

  1. Start a call
  2. Update it from the Ruby client

Code Snippet

# Example for ending a call from the server

Twilio::REST::Client.new.calls(twilio_call_sid).update(
  status: :completed
)

Exception/Log

Completed parameter was sent but so were the other parameters.

image

Technical details:

(Twilio Ticket 15197987)

manisha1997 commented 1 month ago

Hi @jon-sully , The update method has documentation https://github.com/twilio/twilio-ruby/blob/53a8b592ccff56de97671f046ca030e44246c73a/lib/twilio-ruby/rest/api/v2010/account/call.rb#L829, you can take a look at the update method and customize it based on your requirements.

jon-sully commented 1 month ago

Hey there! Yes, I see that — but my understanding of the intention behind the Twilio SDK when it was written is that leaving it as :unset (by not passing anything in) would omit the parameter from the request entirely. My original issue is that I didn't set the parameter in my method call (so the underlying value would've been set to :unset) but the the value still was sent in the ultimate API POST, which, and this may be a back-end bug to determine, overrides the status callback URL already stored on that call resource.

I would think that if I have a Call resource saved and set on the back-end and a request comes in to the back end with status_callback_url: "", the empty string shouldn't override the present value on the previously-saved copy of that Call, but that's just my take.

Either way, since I'm specifically not passing a value for that particular key, I'd have expected it to not be present in the ultimate POST the SDK generates (issue 1.) and, even if it is, since it's sent with an empty value, I'd expect the back end to not overwrite my existing status_callback_url with said empty value.