Who does the work when Cloud Tasks sends a request?

The queue holds the task. A handler, the code at the receiving address, actually does the work. You need a Google Cloud project and a receiver you control. Configure and verify who can call it.

Tell the user their report was requested when the queue accepts it. Show Ready only after your app records that the report exists.

What if a report finishes but the queue never sees the reply?

Cloud Tasks can send a task again after a failed reply or timeout. Use a stable report ID and make the receiver look up or safely reuse the report for that ID. A task name can stop a duplicate from being added during the queue’s limited name-retention period. It cannot stop a retry of the same delivery.

What does a busy queue cost and what history remains?

Google counts API calls and delivery attempts, including retries, in 32 KB chunks. The posted rate gives the first million operations per account each month at no charge and lists US$0.40 per million above that. Your handler hosting is separate. An ordinary HTTP task has a configurable deadline up to 30 minutes.

A completed task is removed. Keep your app’s result or failure record separately. To move, keep the handler code and a description of the task format, retry rules, rate limits and authentication. Check which app records still need work before creating jobs in the replacement queue.

How would you rehearse a reply that arrives too late?

Use a sheet of paper and an imaginary report. Do not make a cloud queue or send a request.

Record the first attempt
Write that report R-14 was saved and the reply arrived after the deadline. The app’s record points to one finished report.
Read the same task again
Use R-14 to find the saved file and return its existing result. The expected check is two attempts and one report.
Check the failure boundary
For another report that never saved, show failed or needs review after the retry budget. Do not mark it ready.