fix(jitsu-cli): fetch function list once, not per file

[vklimontovich]

Summary

jitsu-cli deploy was making O(N²) requests to the console: for every function being deployed, deployFunction() re-fetched the entire workspace function list (including each function's code blob) just to resolve slug → id. On fusionmedialimited/jitsu-functions (≈63 functions) that's ~63 list calls × 63 rows = ~3,900 row reads per deploy, on top of the 63 PUTs. It's the visible cause of console pod CPU spikes during deploys.

This PR hoists the GET /api/<ws>/config/function call out of the per-file loop into deployFunctions(), builds slug/id lookup maps once, and passes them down. Network and DB load drop from N + N×N to N + 1.

Why this matters

• Deploys touching the clpwf99ji0000jp0fi5hl01t8 workspace currently take ~4 min and pin one or two console pods to high CPU for that window (see run 26035361978). The hot path was the redundant list fetch, not the write.
• The list endpoint (pages/api/[workspaceId]/config/[type]/index.ts) returns every config object's full config JSON; for functions that includes the compiled code. Multiplying that by N is wasteful even ignoring DB load.

Behavior preserved

• Same lookup semantics: slug first, fall back to meta.id.
• Same error path on initial list failure (process.exit(1)).
• deployFunction() keeps an optional default-empty lookup so it stays callable standalone (e.g. from tests).
• No change to the POST / PUT payloads or to profile-builder handling.

Test plan

• pnpm typecheck in cli/jitsu-cli
• pnpm build in cli/jitsu-cli
• Manual: run pnpm jitsu-cli deploy --workspace … --apikey … against the QA workspace and confirm all functions deploy + console CPU stays flat
• Confirm release lands in the published jitsu-cli package so the fusionmedialimited/jitsu-functions CI picks it up

Out of scope (follow-ups worth doing)

• The same loop also calls deployFunction with kind === "profile" but the GET inside still hit /config/function — looks like a long-standing bug (profiles never resolve their existingFunctionId, so they get POSTed-new every deploy). Preserving for now to keep this PR minimal.
• Console-side: add ?fields=id,slug projection on the list endpoint so even the single hoisted call doesn't pull every function's code.
• Console-side: add CPU/memory requests/limits + HPA to jitsu-console (separate PR in jitsu-cloud-infra).

[jitsu-code-review]

Found a few correctness regressions in the provided change range:

1. High — Firestore pagination can skip/duplicate documents

   • bulker/connectors/firebase/firebase.go:284,350
   • The first batch is fetched with collection.Limit(batchSize) (no deterministic ordering), but subsequent batches switch to OrderBy(firestore.DocumentID).StartAfter(lastDoc.Ref.ID). Using a cursor derived from an unordered page against an ordered query is not stable, so large collections can miss or re-read records.
   • Please keep the ordering consistent from the first page (same OrderBy for every batch) and use the same cursor form across pages.

2. Medium — CRON_ENABLED is no longer respected

   • docker-start-console.sh:14-15
   • init() now always starts cron, whereas previous behavior honored CRON_ENABLED=0/no/false.
   • This is a user-visible behavior change and can trigger background jobs in environments that explicitly disabled cron.

3. Medium — API rate limiting protections were removed without replacement

   • webapps/console/lib/api.ts (rate limiter enforcement block removed in nextJsApiHandler), and webapps/console/pages/api/workspace/index.ts (POST route-specific cap removed).
   • This drops request throttling safeguards, including the explicit workspace-creation cap, and reopens abuse/DoS paths for authenticated traffic.
   • If this is intentional, we need an equivalent protection at another layer before merging.

review is bugged

[jitsu-code-review]

Thanks for the perf improvement here. I found one behavior regression that should be fixed before merge.

[jitsu-code-review]

Caching this list once changes deploy semantics within a single run: after a successful create, the cache is not updated, so later files still see not found and can attempt a second POST for the same slug/id.

Before this change, each file re-fetched and the second file switched to PUT. Please update the cache after successful POST (and on relevant PUT slug changes) to preserve previous behavior.

[absorbb]

Good catch — fixed in d5659c9. Two helpers now mutate the cache on success: cacheAfterCreate (POST) inserts the new {id, slug} into both maps, cacheAfterUpdate (PUT) refreshes the slug index (dropping the old slug → id link when the slug was renamed). The entry is the same object reference in byId and bySlug, so one mutation covers both. A second file with the same slug now resolves to the freshly-created id and switches to PUT, matching the pre-hoist behavior.

[jitsu-code-review]

Reviewed the changes in this PR.

The hoisted existing-function cache preserves deploy semantics while reducing redundant API calls; I did not find correctness, security, or user-visible regression issues in the changed code.

[jitsu-code-review]

Reviewed the deploy cache changes in cli/jitsu-cli/src/commands/deploy.ts. The hoisted function-list fetch and cache synchronization on POST/PUT look correct, and I did not find actionable bugs, security issues, or user-visible regressions in this patch.