Run Timeout design/reconciliation
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 21
- Forks
- 23
- Avg merge
- 1d 22h
- Merged PRs (30d)
- 17
Description
What is a timeout?
The runtime supports a timeout, which is actually a timeout for each job. If the timeout is set at 1 minute, then each job has 1 minute to run. Not an unreasonable design, biased by the initial runtime implementation which just executed a single expression, not a whole workflow.
Lightning will want to send a timeout to the Worker for an attempt. Is this a timeout for the whole attempt, or per run?
I don't know whether we should support AttemptTimeout and JobTimeout as two distinct options, or whether we should only support an attempt timeout down in the runtime, or what.
This needs a bit of wider thinking.
Design Overview
- Run timeout is tracked in runtime AND engine
- Attempt timeout is tracked in worker
Contributor guide
No contributing guide indexed for this repository
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
Start by tracing timeout handling across the runtime, engine, and worker, where the issue says run and attempt timeouts are tracked. Decide whether timeouts apply per job, per run, or per attempt, and whether separate options are needed; done means the behavior and ownership are clearly specified.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- distributed-systems
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100