fix(v2): validate timeoutSeconds per trigger type (addition) #1877
Open
IzaakGough wants to merge 29 commits into
Open
fix(v2): validate timeoutSeconds per trigger type (addition) #1877IzaakGough wants to merge 29 commits into
IzaakGough wants to merge 29 commits into
Conversation
The v2 SDK accepts any timeoutSeconds value at function-definition
time and leaves the rejection to the Cloud Functions control plane
at deploy time. v1 has had assertRuntimeOptionsValid for a long time
but v2 was missing the equivalent.
Add per-trigger-type validation so misconfigured values fail locally
instead of mid-deploy:
- 540s for event-handling functions (firestore, database, pubsub,
storage, scheduler, eventarc, testLab, remoteConfig, alerts,
dataconnect)
- 3600s for HTTPS and callable functions (onRequest, onCall,
onCallGenkit, identity, dataconnect/graphql, ai)
- 1800s for task queue functions (onTaskDispatched)
Implementation notes:
- New internal helper assertTimeoutSecondsValid(opts, kind) and
MAX_{EVENT,HTTPS,TASK}_TIMEOUT_SECONDS constants in
src/v2/options.ts.
- optionsToEndpoint and optionsToTriggerAnnotations gained an
optional kind argument. When omitted they behave exactly as
before, so existing callers are unaffected.
- Expression<number> and RESET_VALUE are passed through untouched;
the SDK cannot know the concrete value in those cases.
- For providers whose __endpoint is a lazy getter (storage) the
throw happens the first time the manifest is read instead of at
function-definition time; a regression test covers this path.
Fixes #1737
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Code Review
This pull request adds validation for timeoutSeconds across all v2 trigger types, ensuring that misconfigured values are caught during function definition rather than at deployment. It introduces specific limits for event-handling (540s), HTTPS/callable (3600s), and task queue (1800s) functions. Reviewer feedback suggests strengthening the validation logic to explicitly handle non-numeric types (like strings or booleans) and clarifying whether a 0-second timeout is valid according to platform documentation.
IzaakGough
changed the title
added 5 commits
April 23, 2026 16:51
The v2 SDK accepts any timeoutSeconds value at function-definition
time and leaves the rejection to the Cloud Functions control plane
at deploy time. v1 has had assertRuntimeOptionsValid for a long time
but v2 was missing the equivalent.
Add per-trigger-type validation so misconfigured values fail locally
instead of mid-deploy:
- 540s for event-handling functions (firestore, database, pubsub,
storage, scheduler, eventarc, testLab, remoteConfig, alerts,
dataconnect)
- 3600s for HTTPS and callable functions (onRequest, onCall,
onCallGenkit, identity, dataconnect/graphql, ai)
- 1800s for task queue functions (onTaskDispatched)
Implementation notes:
- New internal helper assertTimeoutSecondsValid(opts, kind) and
MAX_{EVENT,HTTPS,TASK}_TIMEOUT_SECONDS constants in
src/v2/options.ts.
- optionsToEndpoint and optionsToTriggerAnnotations gained an
optional kind argument. When omitted they behave exactly as
before, so existing callers are unaffected.
- Expression<number> and RESET_VALUE are passed through untouched;
the SDK cannot know the concrete value in those cases.
- For providers whose __endpoint is a lazy getter (storage) the
throw happens the first time the manifest is read instead of at
function-definition time; a regression test covers this path.
Fixes #1737
CorieW
reviewed
May 14, 2026
cabljac
reviewed
May 14, 2026
cabljac
reviewed
May 14, 2026
ajperel
reviewed
May 15, 2026
ajperel
reviewed
Jun 4, 2026
ajperel
left a comment
ajperel
left a comment
There was a problem hiding this comment.
A little minor feedback but this is very close. Thanks for doing this.
Author
|
@ajperel Thanks for the feedback! Made those suggested changes, let me know if you spot anything else. |
ajperel
approved these changes
Jun 5, 2026
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
5 participants
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.
Supercedes #1877
Fixes #1737
Summary
timeoutSecondsvalidation at function-definition or manifest-extraction time using trigger-specific limits: 0-540s for event handlers, 0-3600s for HTTPS/callable functions, and 0-1800s for task queues.null, and invalid non-number types, while preservingExpressionandRESET_VALUEsupport.Testing
npm test -- --grep "assertTimeoutSecondsValid|optionsToEndpoint timeout validation|optionsToTriggerAnnotations timeout validation|v2 provider timeout validation|timeoutSeconds above"npx prettier --check CHANGELOG.md src/v2/options.ts spec/v2/options.spec.ts spec/v2/providers/timeout.spec.ts spec/v2/providers/https.spec.ts spec/v2/providers/storage.spec.ts spec/v2/providers/pubsub.spec.ts spec/v2/providers/tasks.spec.tsnpm run buildNotes
timeoutSeconds: 0remains accepted to match existing runtime option validation behavior.blockingtimeout kind with the platform-specific cap, validate blocking providers before callingoptionsToEndpoint, or keep the current HTTPS kind until the backend/CLI constraint is confirmed.