---
title: Request Timeouts
weight: 54
---
:icons: font
:sectlinks:
:linkattrs:

In the link:../tutorial/#02-fault-injection[Fault Injection, window="_blank"] step we showed how we could introduce a delay in the critical *hotels* service and test the resilience of the application.

The delay was propagated across services and Kiali showed how services accepted the delay without creating errors on the system.

But in real scenarios delays may have important consequences. Services may prefer to fail sooner, and recover, rather than propagating a delay across services.

This step will show how to add a request timeout for one of the portals deployed in *travel-portal* namespace. The *travel.uk* and *viaggi.it* portals will accept delays but *voyages.fr* will timeout and fail.

NOTE: *Step 1:* Use the Fault Injection Wizard on *hotels* service to inject a delay

Repeat the link:../tutorial/#02-fault-injection[Fault Injection, window="_blank"] step to add delay on *hotels* service.

NOTE: *Step 2:* Use the Request Routing Wizard on *travels* service to add a route rule with delay for *voyages.fr*

Add a rule to add a request timeout only on requests coming from *voyages.fr* portal:

- Use the Request Matching tab to add a matching condition for the *portal* header with *voyages.fr* value.
- Use the Request Timeouts tab to add an HTTP Timeout for this rule.
- Add the rule to the scenario.

++++
<a class="image-popup-fit-height" href="/images/tutorial/05-05-request-timeout-rule.png" title="Request Timeout Rule">
    <img src="/images/tutorial/05-05-request-timeout-rule.png" style="display:block;margin: 0 auto;" />
</a>
++++

{nbsp} +
A first rule should be added to the list like:

++++
<a class="image-popup-fit-height" href="/images/tutorial/05-05-voyages-rule.png" title="Voyages Portal Rule">
    <img src="/images/tutorial/05-05-voyages-rule.png" style="display:block;margin: 0 auto;" />
</a>
++++

{nbsp} +
Add a second rule to match any request and create the scenario. With this configuration, requests coming from *voyages.fr* will match the first rule and all others will match the second rule.

++++
<a class="image-popup-fit-height" href="/images/tutorial/05-05-generic-rule.png" title="Any Request Rule">
    <img src="/images/tutorial/05-05-generic-rule.png" style="display:block;margin: 0 auto;" />
</a>
++++

NOTE: *Step 3:* Review the impact of the request timeout in the *travels* service

When the scenario is created, the Graph will show how requests coming from *voyages.fr* start to fail due to the requests timeout introduced.

Requests coming from other portals work without failures but are degraded by the *hotels* delay.

++++
<a class="image-popup-fit-height" href="/images/tutorial/05-05-travels-graph-voyages-error.png" title="Travels Graph">
    <img src="/images/tutorial/05-05-travels-graph-voyages-error.png" style="display:block;margin: 0 auto;" />
</a>
++++

{nbsp} +
This scenario can be visualized in detail if we examine the "Inbound Metrics" and we group by "Remote app" and "Response code".

++++
<a class="image-popup-fit-height" href="/images/tutorial/05-05-voyages-rule-metrics.png" title="Travels Inbound Metrics">
    <img src="/images/tutorial/05-05-voyages-rule-metrics.png" style="display:block;margin: 0 auto;" />
</a>
++++

{nbsp} +
As expected, the requests coming from *voyages.fr* don't propagate the delay and they fail in the 2 seconds range, meanwhile requests from other portals don't fail but they propagate the delay introduced in the *hotels* service.

NOTE: *Step 4:* Update or delete Istio Configuration

As part of this step you can update the scenarios defined around *hotels* and *travels* services to experiment with more conditions, or you can delete the generated Istio config in both services.
