apps/libs/analytics-api-client/src/configuration.ts (1)

14-24: ⚡ Quick win

Export AWSv4Configuration interface for public API.

The AWSv4Configuration interface is not exported but is used by the public ConfigurationParameters and Configuration types. While TypeScript allows this, consumers cannot directly reference or type-annotate AWSv4Configuration objects, limiting type reusability. Export the interface to make it part of the explicit public API.

📤 Recommended fix

-interface AWSv4Configuration {
+export interface AWSv4Configuration {
   options?: {

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@apps/libs/analytics-api-client/src/configuration.ts` around lines 14 - 24,
The AWSv4Configuration interface is currently unexported but referenced by the
public types ConfigurationParameters and Configuration; export it so consumers
can reference it directly. Update the declaration of AWSv4Configuration to be
exported (export interface AWSv4Configuration) and ensure any imports/users
(e.g., where ConfigurationParameters or Configuration are defined) continue to
compile without other changes.

apps/libs/analytics-api-client/swagger.json (3)

58-60: ⚡ Quick win

Consider adding maxItems constraints to array responses.

Array responses lack maxItems constraints, which could allow unbounded result sets that risk memory exhaustion in clients. For production APIs, consider adding reasonable limits (e.g., 1000 or 10000) and documenting pagination if larger result sets are needed.

🛡️ Example fix for one array response

             "schema": {
               "type": "array",
+              "maxItems": 10000,
               "items": { "$ref": "`#/definitions/models.UsagePeriod`" }
             }

Also applies to: 143-146, 184-187, 260-263, 315-318, 377-380, 419-421

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@apps/libs/analytics-api-client/swagger.json` around lines 58 - 60, Several
array response schemas (e.g., the array whose items reference models.UsagePeriod
and other array definitions in swagger.json) lack maxItems constraints; update
those array definitions to include a reasonable "maxItems" value (e.g., 1000 or
10000) and add accompanying description/notes about pagination where appropriate
so clients cannot receive unbounded arrays. Locate the array schemas that
reference "`#/definitions/models.UsagePeriod`" and the other array entries called
out (around the other occurrences) and add a "maxItems": <limit> property and
documentation text in each schema to enforce and document a practical upper
bound.

Source: Linters/SAST tools

---

1-15: ⚡ Quick win

Add schemes field to specify HTTPS for production.

The spec is missing a schemes field, which defaults to HTTP in Swagger 2.0. For production deployments, the API should enforce HTTPS to protect the Bearer tokens in transit.

🔒 Recommended addition

Add after line 8:

   "host": "localhost:8080",
+  "schemes": ["https"],
   "securityDefinitions": {

For development/testing, you can include both schemes:

"schemes": ["http", "https"],

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@apps/libs/analytics-api-client/swagger.json` around lines 1 - 15, The Swagger
2.0 spec is missing the "schemes" field so it defaults to HTTP; add a "schemes"
entry to the root object in apps/libs/analytics-api-client/swagger.json (near
the existing "swagger" and "info" fields) to include "https" for production
(optionally ["http","https"] for dev/testing) so the API enforces HTTPS for
Bearer token transport.

---

2-2: ⚖️ Poor tradeoff

Consider upgrading to OpenAPI 3.0+ in future iterations.

The spec uses Swagger 2.0, which is the legacy format. OpenAPI 3.0+ offers better tooling support, enhanced security scheme definitions, and improved schema validation. While not blocking for this PR, consider upgrading when time permits.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@apps/libs/analytics-api-client/swagger.json` at line 2, The spec currently
uses Swagger 2.0 (the JSON key "swagger": "2.0"); upgrade it to OpenAPI 3.x by
replacing the top-level "swagger" key with "openapi": "3.0.3" (or later) and
migrating Swagger 2 constructs to OpenAPI 3 equivalents: move "definitions" to
"components.schemas", convert "parameters"/"responses" into "components",
transform any formData parameters into requestBody with content/media type, and
adjust securityDefinitions to components.securitySchemes; you can use a
converter tool like swagger2openapi to automate the migration and then verify
with an OpenAPI 3 validator and update any downstream codegen or tooling that
expects the Swagger 2 format.

apps/libs/analytics-api-client/src/common.ts (1)

69-71: 💤 Low value

Consider handling Set more explicitly to avoid loose type cast.

The code casts parameter as any[] when it could be a Set. While this works because both Array and Set have compatible forEach methods, it's not type-safe. Consider handling them separately or converting Set to Array explicitly for clarity.

♻️ More type-safe alternative

-        if (Array.isArray(parameter) || parameter instanceof Set) {
-            (parameter as any[]).forEach(item => setFlattenedQueryParams(urlSearchParams, item, key));
-        }
+        if (Array.isArray(parameter)) {
+            parameter.forEach(item => setFlattenedQueryParams(urlSearchParams, item, key));
+        }
+        else if (parameter instanceof Set) {
+            Array.from(parameter).forEach(item => setFlattenedQueryParams(urlSearchParams, item, key));
+        }

Alternatively, if you prefer the combined branch:

         if (Array.isArray(parameter) || parameter instanceof Set) {
-            (parameter as any[]).forEach(item => setFlattenedQueryParams(urlSearchParams, item, key));
+            const items = parameter instanceof Set ? Array.from(parameter) : parameter;
+            items.forEach(item => setFlattenedQueryParams(urlSearchParams, item, key));
         }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@apps/libs/analytics-api-client/src/common.ts` around lines 69 - 71, The
branch inside setFlattenedQueryParams that currently does (parameter as
any[]).forEach(...) is not type-safe for Sets; update it to handle Set
explicitly or convert the Set to an array before iterating: detect if parameter
is Array (Array.isArray) then iterate, else if parameter is instance of Set
convert via Array.from(parameter) or use parameter.forEach with proper typing,
then call setFlattenedQueryParams(urlSearchParams, item, key); this preserves
behavior while removing the loose cast and clarifying intent.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes