Timeout issue (BuildShip slow response) + Twilio workaround?
I have the "slow start" upgrade, but it seems like at least one of our workflows is still timing out at 15 seconds sometimes while Twilio is sending SMS messages to us. This is super critical because it means we essentially lose customer messages.
We need a more robust solution to this problem. Is there any way to ensure more robust delivery of messages, perhaps when BuildShip is having trouble, even if our customers have to wait that's ok.
I'm doubtful setting up a second endpoint that queues the response would fix this, but maybe it would? Maybe a proxy with retry logic (that seems like a feature request).
I've also considered setting up a Twilio function that retries the endpoint a few times, which might buy us more time.
Ideas welcomed!
2 Replies
AI Support Bot Information
<@405465071448227840> you can react on the relevant answer (message) with a ✅ in this thread when you think it has been solved, by the bot or by a human!
Anyone can react on this message with a ❌ if the GPT bot is unhelpful or hallucinating answers.
Please note: Team members will review and answer the questions on best efforts basis.
AI Response
It seems that your query doesn't have a direct resolution in the provided resources or FAQs. However, considering your situation with timeouts and message delivery issues, you could explore several strategies:
1. Queueing System with Retry Logic:
- Setting up a queue like Amazon SQS or RabbitMQ can help you manage message delivery asynchronously. You can design your service to place incoming messages into a queue, which can then be processed and sent out as SMS. Repeated delivery attempts can be managed via the queue's retry policies.
2. Proxy with Retry Logic:
- A proxy server that introduces retry logic for failed SMS sending attempts could be beneficial. This way, if the interaction with Twilio fails, the proxy can retry a set number of times before giving up. This may require custom development or the use of an API gateway with built-in retry functionality.
3. Resilient Twilio Function:
- Deploying a Twilio Function that handles retries might be a valid workaround. You can set it to retry the HTTP request to your endpoint multiple times with exponential backoff, reducing the chance of missing messages due to temporary issues.
4. Backup Endpoint:
- A secondary endpoint could be established to handle overflow when your main processing stack is experiencing high latency or timeouts. This approach might be complex, especially ensuring data consistency between the primary and backup systems.
5. Monitoring and Alerting:
- Ensure that you have robust monitoring and alerting around the performance of your SMS sending pipeline. This can help you act quickly to resolve issues before they result in significant message loss.
It might be beneficial to discuss these strategies with your software team to evaluate what fits best within your current architecture and constraints. Should you decide that one of these solutions requires substantial changes or support from BuildShip, it might necessitate reaching out directly for additional features or configurations tailored to your needs.
BuildShip AI Support