You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(storage-resize-images): kit/extension parity – lost uploads are logged as HTTP 200 with no error severity #3267
storage-resize-images kit/extension parity. Priority: medium. Lost uploads don't show up as errors, which is why #3264 goes unnoticed.
Difference
Extension (1st gen): a crash or timeout is reported as a function failure.
Kit (2nd gen): Cloud Run records the request as HTTP 200 and the trigger does not retry. Alerts or error-rate metrics keyed to function failures never fire.
Reproduced
Case
Kit log
20 large images at once (timeout)
200, INFO The request has been terminated because it has reached the maximum request timeout.
10 large images at 512 MB
200, Memory limit of 512 MiB exceeded with 515 MiB used. and no error from the function
SHARP_OPTIONS={bad}
200, stderr SyntaxError: Expected property name or '}' in JSON at position 1 with no severity
In each case the original stays unresized and nothing in the function's own logs is at ERROR.
Log any error from the handler with logger.error (structured, ERROR severity) and rethrow, as proposed for delete-user-data in #3251. In the README, note that 2nd gen request status doesn't reflect failures, and recommend log-based alerts. Timeouts and memory kills can't be caught in the handler, so the fix in #3264 is what removes those.
Activity
storage-resize-imageskit tracking issue #3263