-
Notifications
You must be signed in to change notification settings - Fork 373
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(functions): Add features to task queue functions #2216
Conversation
@@ -58,6 +60,38 @@ export type TaskOptions = DeliverySchedule & TaskOptionsExperimental & { | |||
* The default is 10 minutes. The deadline must be in the range of 15 seconds and 30 minutes. | |||
*/ | |||
dispatchDeadlineSeconds?: number; | |||
/** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: newline between commented fields (e.g. here and headers)
}); | ||
} | ||
|
||
for (const invalidOption of [null, 'abc', '', [], true, 102, 1.2]) { | ||
it(`should throw if options is ${invalidOption}`, () => { | ||
expect(() => apiClient.enqueue({}, FUNCTION_NAME, '', invalidOption as any)) | ||
.to.throw('TaskOptions must be a non-null object'); | ||
expect(apiClient.enqueue({}, FUNCTION_NAME, '', invalidOption as any)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here and elsewhere, you need to make the test case async and then await this expectation or no check will actually be performed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm I deliberately chose to use chai's eventually
to wait on the Promise returned by enqueue
calls instead of async/await, to align better with the existing implementation which generally avoids async/await. Should I go ahead and refactor the unit tests to use async/await instead?
package-lock.json
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we don't make any changes to the package.json
in this PR, let's revert the lock file changes and let dependabot take care of the package-lock.json
updates.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the PR!
Please get a TW review on the documentation changes before merging this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I got a certain way through this and GH told me my diff was outdated . . . submitting these comments so far and will look again, thanks!
src/functions/functions-api.ts
Outdated
* If not provided, one will be automatically generated. | ||
* If provided explicitly specifying a task ID enables task de-duplication. If a task's ID is | ||
* identical to that of an existing task or a task that was deleted or executed recently then | ||
* the call will throw a TaskAlreadyExists error. Another task with the same id can't be |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggest TaskAlreadyExists
and capped "ID" in the next line.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually wanted to get your thoughts on how to document this — instead of throwing a TaskAlreadyExists error, we changed the behavior to throw a FirebaseFunctionsError with code "functions/task-already-exists". So if a user wanted to check if a thrown error is due to the task already existing, they would check like so:
try {
await queue.enqueue(...);
} catch (err: unknown) {
if (err.code === "functions/task-already-exists") {
...
}
}
Is this comment in the functions API sufficient to document this behavior?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Thank you!
Since CF3 released support for Task Queue Functions at Google I/O 2022, users have made several feature requests. This PR enhances the Task Queue functions API to enable the following:
id
to TaskOptions when enqueueing tasks.id
to the newdelete
API.See firebase/firebase-functions#1423 for the sister changes in the functions SDK.
RELEASE NOTES: Headers passed to TaskQueue HTTPS handlers are now available in the context/event. Added the ability to name the tasks by including an
id
when enqueueing tasks. Added the ability to delete an enqueued task if it has not yet completed.