Add features to task queue functions #1423
Conversation
src/common/providers/tasks.ts
Outdated
| executionCount: number; | ||
|
|
||
| /** | ||
| * The schedule time of the task, as an RFC 3339 string in UTC time zone |
There was a problem hiding this comment.
| * The schedule time of the task, as an RFC 3339 string in UTC time zone | |
| * The schedule time of the task, as an RFC 3339 string in UTC time zone. |
src/common/providers/tasks.ts
Outdated
|
|
||
| /** | ||
| * The HTTP response code from the previous retry. | ||
| * Populated via the X-CloudTasks-TaskPreviousResponse header |
There was a problem hiding this comment.
Would suggest putting the additional comments like this under @remark as done here https://github.com/firebase/firebase-functions/blob/master/src/common/providers/https.ts#L148
Or to put it as a single sentence. FYI everything under @remark tag won't show up in the reference docs.
src/common/providers/tasks.ts
Outdated
| const context: TaskContext = { | ||
| queueName: req.header("X-CloudTasks-QueueName"), | ||
| id: req.header("X-CloudTasks-TaskName"), | ||
| retryCount: Number(req.header("X-CloudTasks-TaskRetryCount")), |
There was a problem hiding this comment.
nit* Can we make sure this won't below up if the request header isn't missing for some reason (e.g. when we invoke it in the emulator).
Would prefer having safe default behavior in case these headers are missing for whatever reason (maybe log a warning when that happens?)
There was a problem hiding this comment.
Right now, the context object will just omit the missing headers if they are missing from the request object but still safely dispatch the handler with the context — what scenarios are you thinking about specifically?
There was a problem hiding this comment.
oh i thought this would blow up:
> Number(undefined)
NaN
Not sure if I like NaN but not as bad as I thought.
src/common/providers/tasks.ts
Outdated
| /** | ||
| * Raw request headers. | ||
| */ | ||
| headers?: Record<string, string>; | ||
| } | ||
|
|
||
| /** | ||
| * The request used to call a Task Queue function. |
There was a problem hiding this comment.
Somewhat out of scope here, but "Task Queue" does not need caps.
src/common/providers/tasks.ts
Outdated
|
|
||
| /** | ||
| * The name of the queue. | ||
| * Populated via the X-CloudTasks-QueueName header. |
There was a problem hiding this comment.
Doc strings all look good!
Only question for me is whether "X-CloudTasks-QueueName" should be backticked as a literal. Or is the idea here that we are suggesting variables, where "QueueName" will actually be a unique name, and X maybe a number?
There was a problem hiding this comment.
Yup, per offline, it sounds like we should backtick it for code font as in https://firebase.google.com/docs/functions/callable-reference#request_format_headers and elsewhere.
src/common/providers/tasks.ts
Outdated
| const context: TaskContext = { | ||
| queueName: req.header("X-CloudTasks-QueueName"), | ||
| id: req.header("X-CloudTasks-TaskName"), | ||
| retryCount: Number(req.header("X-CloudTasks-TaskRetryCount")), |
There was a problem hiding this comment.
oh i thought this would blow up:
> Number(undefined)
NaN
Not sure if I like NaN but not as bad as I thought.
Since CF3 released support for Task Queue Functions at Google I/O 2022, users have made several feature requests. This PR augments the existing
TaskContextinterface to enable the following features:idtoTaskOptionswhen enqueueing tasks.idto the newdeleteAPI.See firebase/firebase-admin-node#2216 for the sister changes in the Admin SDK.