I have a requirement where users upload documents, and the system needs to review each document using an AI service and return the review result in JSON format.
On the UI, I have created a document upload functionality. Once a document is uploaded, it is stored in a database table along with its binary data, file name, and file format.
For each uploaded document, I have added an AI Review button. When the user clicks this button:
The main issue I am facing is a timeout error on the UI. In most cases, around 8 out of 10 attempts result in a timeout on the UI, even though the server-side call from both CS and IS is working successfully.
I am now looking to implement a proper retry mechanism for the AI API call.
Could you please suggest the best approach for handling this scenario, particularly:
I have attached the IS file where the actual REST API call is implemented for reference. I would appreciate your recommendation for a robust and maintainable approach.
This looks like a classic case for going async rather than adding more retries. Since the server-side call succeeds but the UI itself times out, the Request Timeout is the actual bottleneck — not the API call.
The documented pattern for this is: don't call the AI service synchronously from the UI action. Save the request to an entity, kick off a Timer to handle the actual API call (Timers run outside the request-timeout window and have their own longer timeout), and have the UI poll/refresh to show the result once the Timer updates the record's status.
https://success.outsystems.com/documentation/11/building_apps/using_timers/
For retry placement and logging, I'd keep both inside the Timer/server wrapper that owns the integration call — but that part's more a design choice than a hard rule.
Thanks for your valuable feedback.
However, the requirement is that the user should be able to initiate the AI document review process by clicking the AI Review button. That's why I initially chose the current synchronous architecture.
Could you please suggest the best way to handle retry logic when an exception or timeout occurs? Would it be better to retry the API call a limited number of times, log the exception details in the database, and display a user-friendly error message on the UI if all retry attempts fail?
My main concern is that this approach may not resolve the underlying issue. As I mentioned earlier, out of 10 attempts, only 2 are successful, while the remaining 8 result in UI timeout errors.
I have decided to change the approach and implement an asynchronous architecture using a fire-and-forget mechanism with UI polling, as you suggested.
I am planning to use BPT to manage the background document review process and JavaScript-based polling on the UI to check the processing status and display the result once it is available.
I am not entirely sure whether BPT is the most suitable option for this scenario, but I would like to explore this approach and implement the polling logic when the user clicks the AI Review button.
Please let me know if you have any suggestions or recommendations for this implementation.
Glad the async direction makes sense for your case. For the retry piece: I'd keep it simple — 2-3 attempts with a short delay between them, inside the BPT activity/server action that calls the API, not on the UI side. Log each failed attempt (exception message, timestamp, attempt number) to an entity, and only mark the request as "Failed" for the UI to show once you've exhausted retries — the UI polling just reads a status field and shows the friendly error message when it sees that.
One thing worth checking: some AI services return 429/503 for transient issues, so it can help to only retry on those specific codes and fail fast on something like a bad payload that won't change on retry.
@Rahul - Can you please help me to implement the retry logic for api exception. I would like to retry for 2 times when i got any kind of exception. Even though it is POST request.