All requests made to the Temporal Cluster by the Client or Worker are gRPC requests.
Sometimes, when these frontend requests can't be completed, you'll see this particular error message: Context: deadline exceeded.
Network interruptions, timeouts, server overload, and Query errors are some of the causes of this error.
The following sections discuss the nature of this error and how to troubleshoot it.
The Temporal Cluster and SDKs emit metrics that can be used to monitor performance and troubleshoot issues. To collect and aggregate these metrics, you can use one of the following tools:
After you enable your monitoring tool, you can relay these metrics to any monitoring and observability platform.
The current Run Id is mutable and can change during a Workflow Retry. You should not rely on storing the current Run Id, or using it for any logical choices, because a Workflow Retry changes the Run Id and can lead to non-determinism issues.
There are many ways to run a Temporal Cluster on your own. However, the right way for you depends entirely on your use case and where you plan to run it. This article aims to maintain a comprehensive list of all the ways we know of.
We added support for Elasticsearch v7+ (ES7) in the v1.7.0 update to the Temporal Server. Elasticsearch v7 introduces several breaking changes, including the removal of mapping types. These changes make Elasticsearch v6 incompatible with Elasticsearch v7.
Running into limits can cause unexpected failures, so be mindful when you design your systems. Here is a list of many hard (error) or soft (warn) limits that you could encounter while using the Temporal Platform.
This page highlights the key differences between Cadence and Temporal that you will need to account for when migrating.