fix(storage-resize-images): degrade gracefully against a partial env - #3002
Conversation
The extension read process.env directly with fallbacks, so a missing variable degraded gracefully; the kit's params layer turned two of those cases into cold-start crashes (#2974's runtime-contract table). Only reachable outside a normal CLI deploy -- library consumers driving the params entry point, emulator runs, or a hand-rolled .env. - IMAGE_TYPE: ListParam.value() JSON-parses the raw var, so an unset value threw SyntaxError. configFromEnv now returns undefined when the var is absent (the resolver falls back to the default image type) and hands non-JSON input through as a raw string, which the resolver's comma-splitting toArray handles -- an extension-style `jpeg,webp` value now works instead of crashing. - FUNCTION_MEMORY: IntParam yields 0 when unset or non-numeric, and normalizeMemory passed "0" through as an invalid memory option. The 0 sentinel now maps to undefined, so the resolver applies its 1GiB default. Not changed: SHARP_OPTIONS ("" already degrades via `|| "{}"` in the resolver) and IS_ANIMATED / REGENERATE_TOKEN (unset reads false on both the extension and the kit). The suite's two crash-characterization tests are superseded by three graceful-degradation tests; the partial-env characterization test now documents the memory exception.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the configuration loading in the storage-resize-images kit to handle unset or legacy comma-separated environment variables gracefully. Specifically, it introduces the imageTypesFromEnv helper to prevent cold-start crashes when IMAGE_TYPE is not valid JSON, and maps FUNCTION_MEMORY to undefined when it is unset or non-numeric so that the resolver can fall back to the default memory. Accompanying unit tests have been added and updated to verify these behaviors. There are no review comments, so no additional feedback is provided.
…ge (#3037) In the kit, an empty `imageTypes` (or empty `sizes`) yields zero resize tasks, `resizeResults.some(...)` is false, and the run counts as success, so under `deleteOriginal: on_success` the original is deleted with nothing produced. The legacy extension avoided this through param validation (`IMAGE_TYPE` is `required: true` in extension.yaml, unset `IMG_SIZES` crashed at module load), not in code: an unset `IMAGE_TYPE` reaching its handler would hit the same zero-task deletion, and an empty-string type actually resizes successfully. Kits have no such install-time gate, so the handler must guard. The fix treats zero resize outputs as a failed run in `generateResizedImageHandler`: `logs.failed()` fires, `handleFailedImage` runs (a no-op without `failedImagesPath`), and deletion only happens when at least one resize actually succeeded. No config-time validation was added, keeping clear of #3002's config changes. Two new vitest cases pin the behavior; the kit's full suite passes (179 passed, 3 skipped). No live Storage E2E was run. Fixes #3007
…llback (#3090) The kit's `checkImageContent` threw `FUNCTION_REGION is required for Vertex AI filtering.` when no region was passed; the extension fell back to `us-central1` (master, storage-resize-images/functions/src/content-filter.ts:121). This restores the fallback at the same point of use: the Vertex AI plugin now receives `location ?? "us-central1"` and the throw is gone. `config.ts` and `export-config.ts` are untouched, so there is no overlap with #3002 and the resolved config still reports `FUNCTION_REGION` faithfully. Normal CLI deploys never hit the throw: firebase-tools injects `FUNCTION_REGION` into every gen2 function's env (verified in 15.26.0, lib/gcp/cloudfunctionsv2.js:197). It was reachable for library consumers of `checkImageContent`, emulator runs, and hand-rolled envs. The throw test is replaced by a fallback test (verified to fail against the old code) plus an explicit-location passthrough test; README, CHANGELOG, and a stale test comment are updated. 182 tests and `tsc --noEmit` pass; the live Vertex filtering path was not exercised. This instantiates a "FUNCTION_REGION if set, else us-central1" rule relevant to the open decision in #3028. Fixes #3023
|
Related to the So a This is the same shape as #3064, which maps the Two things I did not verify: what the installer actually writes to |
3 participants
Summary
process.envdirectly with fallbacks and degraded gracefully against a missing variable; the kit's params layer crashed. Only reachable outside a normal CLI deploy (library consumers of the params entry point, emulator runs, hand-rolled.env).IMAGE_TYPE:ListParam.value()JSON-parses the raw var, so an unset value threwSyntaxErrorat cold start.configFromEnvnow returnsundefinedwhen absent (resolver falls back to the default image type) and passes non-JSON input through as a raw string, which the resolver's comma-splittingtoArrayhandles — an extension-stylejpeg,webpvalue now works instead of crashing.FUNCTION_MEMORY:IntParamyields0when unset or non-numeric, whichnormalizeMemorypassed through as an invalid"0"memory option. The0sentinel now maps toundefined, so the resolver applies its1GiBdefault.SHARP_OPTIONS—""already degrades via|| "{}"in the resolver, so that Kits parity issues #2974 row is stale;IS_ANIMATED/REGENERATE_TOKEN— unset readsfalseon both the extension and the kit.IMAGE_TYPE→["false"], ext-style comma list →["jpeg","webp"], unsetFUNCTION_MEMORY→1GiB); the partial-env characterization test now documents the memory exception.Testing
tsc --noEmitclean; 175 tests pass (6 skipped).