We Keep Coding

Why does my Twilio MessagingResponse not work?

The following Twilio code doesn't work. This is my webhook handler in an ASP.NET (Core) 6.0 app.
[AllowAnonymous]
[HttpPost]
[Route("webhook-url")]
public IActionResult PostTwilioMessageReceived([FromForm] TwilioMessageReceivedFormModel formModel)
{
// logging code etc.
var response = new Twilio.TwiML.MessagingResponse();
response.AddText($"You sent '{formModel.Body}' but our systems are dumb and can't process this yet.");
return new TwiMLResult(response);
}
There are no errors. I don't receive the message, and my delivery status webhook doesn't appear to be called.
The method above is called as I see it in my logs.
Note - There is no "to" address. I have adapted sample code from Twilio's documentation which also does nothing to either read the sender address or configure the response with a recipient or other correlation ID.
https://www.twilio.com/docs/whatsapp/tutorial/send-and-receive-media-messages-whatsapp-csharp-aspnet#generate-twiml-in-your-application
I've modified my logging to make doubly sure my webhook is being called. It is. And in Twilio's log there's no acknowledgement of the reply my webhook attempts to produce.
To be clear, the code above is using Twilio's libraries.

The TwiML output of your application would be:
<Response>You sent '...' but our systems are dumb and can't process this yet.</Response>
Unfortunately, that isn't valid TwiML, instead it should look like this:
<Response>
<Message>You sent '...' but our systems are dumb and can't process this yet.</Message>
</Response>
This will respond with a message to the sender. To do this, use the .Message method instead of .AddText:
response.Message($"You sent '{formModel.Body}' but our systems are dumb and can't process this yet.");
Everything else looks fine in your code AFAIK.
Aside: If all you need to do is to respond to the current sender with a single message, you can also respond with plain text and the text/plain content type.
Edit by OP
I also changed the return line to:
return this.TwiML(response);
Which was the advice of Twilio support. I didn't try it my original way, but assumed that if there was some kind of magic that's pre-addressing the response, or correlating it in some way, then it might be in using the helper function on the base controller. Thanks.

It's hard to say what caused this without seeing an error or message log. You should be able to see something in the "Monitor" in the console (more details here).
I've had similar issues in the past with Node.js and the problem was there that I forgot to set the content-type of the response to text/xml. But I'm not sure if this is required in your C# code.

Is it possible to determine From number used when using copilot messaging service

When i send a text to a customer using a messaging service id. The from number is null in the returned MessageResource. Code below.
Is the only way to determine the From by making an additional call out using the message sid? I need the from used for analytics and so I can use the same number to contact an account in case the customer uses multiple contact numbers.
return await MessageResource.CreateAsync
(
to: new PhoneNumber(toNumber),
messagingServiceSid: messengerSid,
body: message
);

Twilio developer evangelist here.
When you use a messaging service to send messages from various numbers then you cannot know at the time of message creation what the number used will be. When you make the request to send the message, Twilio queues that message up to be delivered by the messaging service. If you inspect the status of the message object you receive from the API call you show in your question you will see it is "accepted". At this point the messaging service won't have decided which number to use.
So, you can either make a second request to the API using the message SID that is returned to find out the From number. Or, you could set a StatusCallback URL which would receive a request once the message was sent, including the From number.
Let me know if that helps at all.

SendGridApiClient get delivery response

Just started working on email sending implementation using SendGridApiClient. Have this line that sends an email
dynamic response = await _sendGrid.client.mail.send.post(requestBody: mail.Get());
Response can provide StatusCode Accepted and nothing more. Was wondering how can I check was email delivered or stuck ?

The SendGrid API is asynchronous because the length of time it takes to process delivery of the email is non-trivial and dependent on factors like the receiving server.
The best way to keep an eye on events like delivered, bounced, etc in real-time is to implement the Event Webhook.
Take a look at this answer: Can my ASP.Net Code get confirmation from sendgrid that an email has been sent?

Async post to Amazon's SQS

I'd like to send messages to Amazon's SQS in a "launch and forget" mode (it's OK for some messages to get lost).
Today, I use this sync code:
webClient.UploadValues(uri, "POST", data);
Since this is going to be heavily used, I want to change this to an async method.
Is there a way to do this (either using plain .net or AWS SDK)?

Found the reason UploadValuesAsync didn't work: It was missing a content-type header:
http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/MakingRequests_MakingQueryRequestsArticle.html#POSTRequests

events v.s. async methods using TaskCompletionSource

I am currently implementing an application protocol library relying on TCP/IP for transport (long lasting connection).
I am trying to achieve a nice asynchronous implementation relying on TAP pattern using C#5 async/await constructs, mainly to put into practice the concepts I have only seen in theory up until now.
The client can connect to a remote server and send requests to it.
client receives response from the server as well as requests (full duplex mode).
From the point of view of the client code, the asynchronous call to my library to send a request to the server and receive the associated response is as simple as :
var rsp = await session.SendRequestAsync(req);
From inside my protocol library, I am just buliding the request, converting it to bytes (to be sent on the network stream) and I call WriteAsync on the stream and I then await on a Task created just before sending the request, making use of a TaskCompletionSource object, which is basically waiting for the associated response to be received (and setting the result on the tcs), and then return the response to the client caller.
This part seems fine.
Now the "problem" concerns the part where server is sending requests to the client. There are different type of requests that the server can send to the client.
My protocol library is using an asynchronous loop to listen to the underlying stream (receiving incoming responses or requests from the server).
This loop is reading responses/requests asynchronously on the stream, then in case of a request from the server, it raises an event corresponding to the request type (such as ReceivedRequestTypeA). The client code can subscribe to these events to be notified when a specific request type is received from the server. The event args of these contains all the parameters associated with the request as well as a response object, to be set by the client, which will be asynchronously sent on the stream by library once event handler code is completed.
The code for the asynchronous listen loop is as follow. Please do not mind the while true, not very pretty (cancelation pattern should be used instead), but this is not the point !
private async Task ListenAsync()
{
while(true)
{
Request req = await ReadRequestAsync();
await OnReceivedRequest(req);
}
}
So the loop is calling the asynchronous method ReadRequestAsync which is just reading some bytes asynchronously in the stream until a complete request or response is available.
Then it forwards the request to the asynchronous method OnReceivedRequest which code can be seen below :
private async Task OnReceivedRequest(Request req)
{
var eventArgs = new ReceivedRequestEventArgs { Req = req };
if (req is RequestTypeA)
{ ReceivedRequestTypeA(this, eventArgs); }
[... Other request types ...]
await SendResponseAsync(eventArgs.Resp);
}
This asynchronous method raise the appropriate request type event.
The client code is subscribed to this event, so its appropriate event handler method is called ... the client code does whatever it needs with the request and then construct a response and set it in the EventArgs object -end of event handler method-. The code resumes in OnReceivedRequest in the library, and the response is sent asynchronously (calling WriteAsync on the underlying stream).
I don't think this is a good approach, as it can completely block the asynchronous loop in the library if the event handler code on client side is doing a lengthy blocking operation (bye bye fully asynchronous protocol library, you are now becoming somehow synchronous due to client code). The same would happened if I was using an asynchronous task based delegate for events and awaiting on it.
I was thinking that instead of using events, I could have an asynchronous method GetRequestTypeAAsync() which would be implemented using TaskCompletionSource object in library, and the tcs result being set with the request in OnReceivedRequest. And on client code side, instead of subscribing to ReceivedRequestTypeA event, the code would rather consist of a loop arround GetRequestTypeAAsync(). Still as the client code must somehow provide a response to the library to be sent to server, I don't know how this could work ...
My brain is completely fuzzy right now and can't really think clear. Any suggestion for a nice design will be greatly appreciated.
Thanks !

I'm also working on async/await TCP/IP sockets, and I strongly recommend you take a look at TPL Dataflow. It's pretty easy to make async-friendly endpoints using two BufferBlocks (one for reads and one for writes).
In my system, the TCP/IP socket wrapper exposes a simple ISourceBlock<ArraySegment<byte>> representing the raw reads. This is then linked to a TransformManyBlock which performs message framing, and from there it can be linked to a TransformBlock which parses the bytes into actual message instances.
This approach works best if you have a RequestType base class from which all your other message types inherit. Then you can have a single receiving task that just (asynchronously) receives RequestType message instances from the end of the dataflow pipeline.