Sean KaneandGitHub c3e0e167e0 Fix TestWorkflowStartConflict flaky test (#9776)
## What changed?
Fix flaky test
`TestUpdateWithStartSuite/TestWorkflowStartConflict/workflow_id_conflict_policy_fail:_use-existing`
handling both possible orderings of the race condition it tests.

## Why?

The test injects a hook (`UpdateWithStartInBetweenLockAndStart`) that
fires a concurrent `StartWorkflowExecution` between the
update-with-start lock acquisition and start attempt to simulate a race
condition. The test assumes the update always lands in a second
speculative WFT:

1. WFT #1 polled with no messages → completed (empty)
2. UWS retry creates speculative WFT #2 → polled with update →
accepted/completed

This assumption broke after the `parallelsuite` migration, which gives
each test its own isolated `testcore.NewEnv` running in parallel. With a
dedicated env, the retryable history client's immediate retry of the
Unavailable error races tightly with `RecordWorkflowTaskStarted`:

- Ordering A (retry wins the lock first): the update is admitted while
WFT #1 is still scheduled, so it attaches to WFT #1's messages when the
worker polls it. No WFT #2 is ever created.
- Ordering B (RecordWorkflowTaskStarted wins): WFT #1 starts and
completes with no messages, then the retry runs with no pending WFT,
creating speculative WFT #2 with the update.

The original two-poll design panicked in ordering A (index out of range
[0] with length 0 on task.Messages[0] in the empty-response first poll).
The initial single-poll fix panicked in ordering B for the same reason.
Neither ordering is
guaranteed, so the test must handle both.

## How did you test it?
- [ ] built
- [X] run locally and tested manually - tested with `-count=50` locally
- [ ] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)

## Potential risks
None, test only
2026-04-02 16:48:04 +00:00
2026-03-30 15:30:50 -07:00
2026-03-30 15:30:50 -07:00
2026-03-13 18:50:16 +00:00
2026-03-30 18:39:49 +00:00
2026-03-30 15:30:50 -07:00
2026-03-30 15:30:50 -07:00
2025-04-07 18:42:37 -07:00

Temporal—durable execution platform

GitHub Release GitHub License Code Coverage Community Go Report Card

Introduction   •   Getting Started   •   Contributing   •   Temporal Docs   •   Temporal 101

Introduction

Temporal is a durable execution platform that enables developers to build scalable applications without sacrificing productivity or reliability. The Temporal server executes units of application logic called Workflows in a resilient manner that automatically handles intermittent failures, and retries failed operations.

Temporal is a mature technology that originated as a fork of Uber's Cadence. It is developed by Temporal Technologies, a startup by the creators of Cadence.

image

Getting Started

Download and Start Temporal Server Locally

Execute the following commands to start a pre-built image along with all the dependencies.

brew install temporal
temporal server start-dev

Refer to Temporal CLI documentation for more installation options.

Run the Samples

Clone or download samples for Go or Java and run them with the local Temporal server. We have a number of HelloWorld type scenarios available, as well as more advanced ones. Note that the sets of samples are currently different between Go and Java.

Use CLI

Use Temporal CLI to interact with the running Temporal server.

temporal operator namespace list
temporal workflow list

Use Temporal Web UI

Try Temporal Web UI by opening http://localhost:8233 for viewing your sample workflows executing on Temporal.

Repository

This repository contains the source code of the Temporal server. To implement Workflows, Activities and Workers, use one of the supported languages.

Contributing

We'd love your help in making Temporal great.

Helpful links to get started:

License

MIT License

S
Description
No description provided
Readme MIT
139 MiB
Languages
Go 85.4%
TypeScript 12.3%
ZAP 1%
Shell 0.6%
Dockerfile 0.4%
Other 0.2%