https://sonarly.com/issue/18934?type=bug
Workflow code steps fail with ARCHIVE_NOT_FOUND when the Lambda driver tries to build an SDK layer for applications that were installed before the SDK client generation feature was introduced in PR #18544.
Fix: ## What changed
Modified `SdkClientArchiveService` to auto-generate the SDK client archive when it's missing from file storage, instead of immediately throwing `ARCHIVE_NOT_FOUND`.
### The problem
PR #18544 refactored SDK client provisioning so that `LambdaDriver.ensureSdkLayer()` and `LocalDriver.ensureSdkLayer()` both require a pre-generated `twenty-client-sdk.zip` archive in S3. This archive is generated during workspace creation and app installation, but **not** for applications that were installed before the refactor. A 1.20 upgrade command (`1-20-generate-application-sdk-clients`) exists to backfill, but hasn't run on v1.19.8.
### The fix
In `SdkClientArchiveService.readArchiveStream()`, when the `FILE_NOT_FOUND` error is caught from file storage, instead of throwing `ARCHIVE_NOT_FOUND`, the service now:
1. Looks up the application by `workspaceId` + `universalIdentifier`
2. If the application exists, calls `SdkClientGenerationService.generateSdkClientForApplication()` to generate the archive on-the-fly
3. Retries reading the archive from storage
4. If the application doesn't exist, throws the original `ARCHIVE_NOT_FOUND` error
This is a self-healing approach: the first workflow execution for a pre-existing application will be slower (due to on-the-fly generation), but subsequent executions use the cached archive. The fix covers both the Lambda and Local drivers since they share the same `readArchiveStream` code path.
The `SdkClientGenerationService` is injected via `forwardRef` as a defensive measure since both services live in the same NestJS module (`SdkClientModule`).
Sonarly Claude Code
afebb034fc