docs: clarify TTL, execution timeout, and result retention#525
Open
justinwlin wants to merge 7 commits intomainfrom
Open
docs: clarify TTL, execution timeout, and result retention#525justinwlin wants to merge 7 commits intomainfrom
justinwlin wants to merge 7 commits intomainfrom
Conversation
- Clarify that TTL controls job data retention while queued/in progress - Clarify that execution timeout controls max runtime during processing - Add new 'Result retention' section explaining post-completion retention: - Async (/run): 30 minutes fixed - Sync (/runsync): 1 minute default, extendable to 5 minutes - Add section on configuring long-running jobs (>24 hours) - Update policy options table with clearer descriptions
- Add warning that system does not validate TTL >= executionTimeout - Clarify that if TTL expires before job completes, data is deleted - Emphasize the need to set both for long-running jobs
- ?wait controls how long the request waits for job completion (default 90s, max 5min) - ?wait does NOT extend result retention - Result retention is fixed: 30 min (async), 1 min (sync) - Updated both endpoint-configurations.mdx and send-requests.mdx
Based on code investigation, TTL and execution timeout have NO maximum enforced - only minimums: - TTL: min 10,000 ms (ai-api/pkg/job/job.go:169-171) - executionTimeout: min 5,000 ms (ai-api/pkg/job/job.go:173-175) The '7 days max' was not found in any validation code across: - ai-api (job processing) - main-ui (frontend validation) - runpod-backend (GraphQL schema)
- Explain that TTL timer starts at job submission, not execution start - Add warning that jobs can expire in queue if TTL is too short - Add clear example showing TTL vs execution timeout interaction - Remove duplicate code example
justinwlin
force-pushed
the
docs/clarify-ttl-execution-timeout
branch
from
6e3fc83 to
5b18329
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Clarifies the distinction between TTL, execution timeout, and result retention for serverless jobs.
Key Clarifications
TTL (time-to-live): How long job data is retained in the system. Covers both queue time and execution time - timer starts when job is submitted, not when execution begins. Default 24 hours, max 7 days.
Execution timeout: Maximum time a job can run once a worker picks it up. Default 10 minutes, max 7 days.
Result retention: Fixed period after job completion (30 min async, 1 min sync). Cannot be extended.
?waitparameter: Controls how long the HTTP request waits for completion, NOT result retention.Changes
endpoint-configurations.mdx:send-requests.mdx:?waitdocumentation (controls wait time, not retention)Code References
All validation found in
ai-apirepo:pkg/job/job.gopkg/job/job.gopkg/job/job.gopkg/job/job.gopkg/job/job.gopkg/job/job.go?waitparam parsing (default 90s, range 1-300s)pkg/api/runsync.go?waitused for HTTP blocking, not retentionpkg/api/runsync.go