fix(storage-resize-images): kit/extension parity – large images are silently lost under load (concurrency 80) #3264

storage-resize-images kit/extension parity. Priority: critical. Images are left unresized when several large uploads arrive together, and no error is reported.

Difference

The kit's trigger uses the 2nd gen defaults, so one instance takes up to 80 uploads at once. The extension's 1st gen function takes one upload per instance. Several large decodes then share one instance's memory and CPU, and every upload in flight is lost when it runs out of memory or time. Retries are off, and Cloud Run still logs the requests as 200.

Reproduced

Near-simultaneous copies of an 8000x8000 jpeg (41.5 MB), the same into each side's bucket:

• At 1024 MB, 18 to 20 of the requests went to one kit instance and hit the 60 second timeout. Each lost image logged only The request has been terminated because it has reached the maximum request timeout. at INFO. Ten images at once all succeeded, but took 30 to 36 seconds each. On the extension they took 5 to 7 seconds.
• At 512 MB the kit instance was killed with Memory limit of 512 MiB exceeded with 515 MiB used.
• A single 8000x8000 jpeg at 512 MB succeeded on both. 100 ordinary 1200x800 uploads were 100/100 on both.

Code

• Extension: 1st gen resource (extension.yaml#L56-L63).
• Kit: the trigger sets only region, bucket and memory (index.ts#L100-L107). The README's "The trigger is 2nd gen" section covers memory, not concurrency.

Resolution

Declare concurrency: 1 and cpu: "gcf_gen1" on generateResizedImage, as #3209 (firestore-bigquery-export) and #3233 (firestore-send-email) do. #3206 does not include this kit. The burst has not been re-run with that change.