The command firebase -help lists the available commands and firebase -help shows more details for an individual command. AFAIK, this doesn't have any negative effect because "invocation task" didn't do anything with the result of the "http task" anyway. The result is that "invocation task" now fire-and-forget an "http task". This PR proposes that "invocation task" doesn't wait for the corresponding "http task" to complete, effectively breaking the deadlock. In debug mode this causes the invocation task to wait forever - the "http task" is stuck behind its "invocation task" in the queue.
The code today is written such that an "invocation task" will wait for the corresponding "http task" to complete. Each "invocation task" begets exactly one "http task". So, a call to the multicast route begets zero or more "invocation task" (one per trigger). When the Function Emulator receives an HTTP request for function invocation, it submits a new task to the work queue to handle the http request. Let's call this task an "invocation task". storage and auth triggers), Functions Emulator submits a task per function associated with the event to the work queue where each task makes call to the event function via its HTTP endpoint.
When event functions are triggered via the multicast route (e.g. When Functions Emulator runs in debug mode, the work queue runs in `SEQUENTIAL` mode where tasks are processed one by one in FIFO order. Internally, the Functions Emulator maintains a work queue which processes unit of work called "tasks" with configured parallelism. Fix bug where event triggered functions failed in debug mode ( #5211 ) A classic case of deadlock!
0 kommentar(er)
