temporalio / temporalio/temporal
Matching task dispatch busy loop when history service is not available
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 23.2k
- Forks
- 1.9k
- Avg merge
- 2d 8h
- Merged PRs (30d)
- 228
Description
Expected Behavior
If history service is not running, matching service ideally should not generate lots of DB requests.
Actual Behavior
When task in matching tasks table failed to be dispatched, the loaded task will be acked and a new task will be created. This is essentially a busy loop and consume tons of persistence resources.
This logic exists today to prevent one bad task from blocking the entire task queue I think.
Steps to Reproduce the Problem
Specifications
- Version:
- Platform:
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Trace matching task dispatch when the history service is unavailable, focusing on the path where a failed dispatch is acknowledged and recreated. The issue names no files, tests, or entry points, and its reproduction steps are empty; done means preventing the resulting busy loop and excessive persistence requests without blocking the task queue.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- backend, distributed-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100