Cloud Functions Gen2 with Golang - Instance Lifetime and BigQuery Insertion Safety without Awaiting Job Completion

I'm working with a Google Cloud Function (Gen2) written in Golang, which is triggered by an HTTP request. My use case requires storing some data in BigQuery, and I would like to avoid waiting for the job to complete before responding to the HTTP request.

However, I have concerns regarding the behavior of the Cloud Function instance after returning from the function:

How long does the instance remain alive after sending the HTTP response?
Is it safe not to wait for the BigQuery job to finish? Do I run the risk of losing data if the instance is terminated before the job completes?
Any insight or best practices regarding this scenario would be greatly appreciated.

This approach is discouraged. See the docs below:

> ### Function execution timeline
>
> A function has access to its allocated resources (memory and CPU) only for the duration of function execution. Code run outside of the execution period is not guaranteed to execute, and it can be stopped at any time. Therefore, you should always signal the end of your function execution correctly and avoid running any code beyond it.

> ### Do not start background activities
>
> Background activity is anything that happens after your function has terminated. A function invocation finishes once the function returns or otherwise signals completion, such as by calling the callback argument in Node.js event-driven functions. Any code run after graceful termination cannot access the CPU and will not make any progress.
>
> In addition, when a subsequent invocation is executed in the same environment, your background activity resumes, interfering with the new invocation. This may lead to unexpected behavior and errors that are hard to diagnose. Accessing the network after a function terminates usually leads to connections being reset (ECONNRESET error code).
>
> Background activity can often be detected in logs from individual invocations, by finding anything that is logged after the line saying that the invocation finished. Background activity can sometimes be buried deeper in the code, especially when asynchronous operations such as callbacks or timers are present. Review your code to make sure all asynchronous operations finish before you terminate the function.

An alternative solution is to implement it as an event-driven function (see Types of Cloud Functions). And then specify a Pub/Sub trigger and a Pub/Sub topic for this function (see Pub/Sub triggers). The client has to be rewritten to publish events to this topic.

If the client can not be rewritten, a workaround is to keep both the HTTP function and the event-driven function, and make the HTTP function offload the work to the event-driven function by publishing an event to the topic. Depending on the size of the event and the execution time of the BigQuery job, maybe it won't let the client wait for less time. And I think this approach will increase the cost remarkably.