feat: tenant filtering on redis and s3 - #150

framework/infrastructure/S3/index.ts (1)

83-90: Fail explicitly on encrypted reads without matching compliance.

Right now a missing or wrong compliance context falls through to JSON.parse(body) and surfaces as a generic syntax error. Throwing a targeted decryption/context error here would make tenant mismatches much easier to diagnose and matches the explicit failure you added in EncryptedType.

♻️ Proposed refinement

   private decryptBody(body: string, compliance?: ComplianceContext): string {
-    if (!compliance || !this.encryptor) return body;
+    if (!this.encryptor) return body;
+    if (!compliance) {
+      if (isEncrypted(body)) {
+        throw new Error('Encrypted object requires a compliance context');
+      }
+      return body;
+    }
     if (!isEncrypted(body)) return body;
-    try {
-      return this.encryptor.decrypt(body, compliance.tenantId) ?? body;
-    } catch {
-      return body;
-    }
+    const decrypted = this.encryptor.decrypt(body, compliance.tenantId);
+    if (decrypted === null) {
+      throw new Error('Failed to decrypt object for the provided tenant');
+    }
+    return decrypted;
   }

Also applies to: 163-176

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@framework/infrastructure/S3/index.ts` around lines 83 - 90, The decryptBody
method currently returns the raw body when compliance is missing or decryptor
fails, which causes downstream JSON.parse to surface generic syntax errors;
update decryptBody (and the similar logic around the other occurrence at lines
163-176) to explicitly throw a descriptive DecryptionContextError (or a new
error type) when the payload is encrypted but compliance is absent/mismatched or
when decryptor throws, include tenantId and a short context message referencing
the EncryptedType expectation so callers can distinguish tenant/decryption
issues from JSON syntax errors.

framework/infrastructure/S3/__test__/s3ObjectStore.test.ts (1)

50-59: This setup change still doesn't test the new compliance flow.

All specs here continue to exercise streaming downloads, which intentionally bypass encryption/decryption. Please add putObject/readObject coverage with a ComplianceContext — plus a wrong-tenant or missing-context read — so the per-operation encryption logic is actually validated.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@framework/infrastructure/S3/__test__/s3ObjectStore.test.ts` around lines 50 -
59, The tests currently created by makeStore only exercise streaming downloads
which skip encryption; add unit tests that call S3ObjectStore.putObject and
S3ObjectStore.readObject (not the streaming path) using a ComplianceContext so
the FieldEncryptor logic runs: create a ComplianceContext with the correct
tenant id and pass it into putObject, then readObject with the same context to
assert decrypted payload matches original; also add two negative tests — one
readObject with a wrong-tenant ComplianceContext and one readObject with no
ComplianceContext — and assert those reads fail or return unenforced/blocked
results per the compliance policy. Use the existing makeStore helper to
construct the S3ObjectStore (FieldEncryptor('test-encryption-key-for-s3-tests'))
and reuse or stub mockSend to verify encrypted payloads were sent where
appropriate.

framework/infrastructure/redis/__test__/redisTtlCache.test.ts (1)

18-31: Add a tenant-scoped round-trip test.

This suite now always wires an encryptor, but every assertion still calls Redis without a ComplianceContext, so the new per-tenant encryption path is never exercised. Please add at least one { tenantId } write/read and one mismatched-tenant read so regressions show up in CI.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@framework/infrastructure/redis/__test__/redisTtlCache.test.ts` around lines
18 - 31, Add tests in redisTtlCache.test.ts that exercise per-tenant encryption
by performing a tenant-scoped write/read and a mismatched-tenant read: use the
existing RedisTtlCache instance and call its set(...) to store a key with a
ComplianceContext containing { tenantId: 'tenant-A' } then call get(...) with
the same ComplianceContext and assert the original value is returned; then call
get(...) with a different ComplianceContext ({ tenantId: 'tenant-B' } or no
tenant) and assert the value is not readable (null/undefined or decryption
failure as the suite expects). Locate calls to RedisTtlCache.set and
RedisTtlCache.get (and the ComplianceContext type/constructor) in the test file
and add these two assertions so the tenant-scoped encryption path is covered.

framework/infrastructure/redis/index.ts (2)

84-91: Make plaintext writes an explicit opt-in.

This class already requires RedisCacheEncryptionOptions, but encryptValue treats missing compliance as “store plaintext”. That makes undefined ambiguous: it can mean “plaintext by design” or “caller forgot to thread the new tenant context”, and both succeed silently.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@framework/infrastructure/redis/index.ts` around lines 84 - 91, encryptValue
currently treats a missing ComplianceContext as implicit permission to write
plaintext; change this so plaintext writes are explicit by requiring an explicit
opt-in flag or by making ComplianceContext mandatory. Update the encryptValue
signature (currently encryptValue(serialized: string, compliance?:
ComplianceContext)) to either require compliance or add a boolean allowPlaintext
parameter defaulting to false, and make the method throw or return an error when
compliance is undefined and allowPlaintext is not true; ensure you reference the
class-level encryptor and ComplianceContext in the check and update all callers
of encryptValue (and any wrapper methods) to pass the compliance or explicit
allowPlaintext flag.

---

1-14: Move redis into the external-dependency layer.

The new import block places the external redis package after the @forklaunch/* imports, which breaks the repository's import layering.

♻️ Proposed cleanup

+import { createClient, RedisClientOptions } from 'redis';
 import { safeParse, safeStringify } from '@forklaunch/common';
 import {
   type ComplianceContext,
   TtlCache,
   TtlCacheRecord
 } from '@forklaunch/core/cache';
 import {
   evaluateTelemetryOptions,
   MetricsDefinition,
   OpenTelemetryCollector,
   TelemetryOptions
 } from '@forklaunch/core/http';
 import { type FieldEncryptor } from '@forklaunch/core/persistence';
-import { createClient, RedisClientOptions } from 'redis';

As per coding guidelines, "Organize imports in 7 layers: (1) Node built-ins with node: prefix, (2) External dependencies, (3) Forklaunch framework packages, (4) Cross-module imports, (5) Local persistence, (6) Local domain, (7) Same directory".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@framework/infrastructure/redis/index.ts` around lines 1 - 14, The redis
import (createClient, RedisClientOptions) is placed after the `@forklaunch/`*
imports which breaks the 7-layer import ordering; move the "redis" import into
the external-dependencies layer so it appears before any `@forklaunch/`* imports,
keeping the existing symbols (createClient, RedisClientOptions) intact and
preserving the rest of the import block order.

framework/core/src/cache/interfaces/ttlCache.interface.ts (1)

17-28: Update the in-tree TtlCache doubles with the new compliance argument.

Because this parameter is optional, old object-literal mocks keep compiling even if they never exercise the tenant-scoped path. The doubles in framework/core/__test__/rateLimiter.test.ts:10-40 and framework/core/__test__/rateLimiter.test.ts:57-76 still use the pre-change readRecord/putRecord shape.

Also applies to: 78-89

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@framework/core/src/cache/interfaces/ttlCache.interface.ts` around lines 17 -
28, Update the in-test TtlCache doubles to match the new method signatures that
accept an optional ComplianceContext: update the mocked methods
readRecord<T>(key: string, compliance?: ComplianceContext),
putRecord<T>(cacheRecord: TtlCacheRecord<T>, compliance?: ComplianceContext) and
putBatchRecords<T>(cacheRecords: TtlCacheRecord<T>[], compliance?:
ComplianceContext) so tests in the rate limiter mocks call/implement the extra
optional parameter (leave behavior the same when compliance is undefined).
Locate the doubles by the TtlCache/readRecord/putRecord/putBatchRecords
identifiers used in the tests and add the optional parameter to their function
signatures and any places that construct or call them.

Fix all unresolved CodeRabbit comments on this PR:

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

framework/core/src/persistence/encryptedType.ts (1)

209-217: Consider including tenantId in the decryption error for easier debugging.

When decryption fails due to a tenant context mismatch (e.g., data encrypted with tenant A but decrypted in an empty context or tenant B's context), the current error message doesn't hint at this common cause. Including the tenantId value would help diagnose these issues faster, especially given that getCurrentTenantId() returns '' during startup, seeders, and background jobs (per the comment on line 50).

💡 Suggested enhancement

     let decrypted: string | null;
     const tenantId = getCurrentTenantId();
     try {
       decrypted = _encryptor.decrypt(value, tenantId);
     } catch (err) {
       throw new Error(
-        `Failed to decrypt encrypted column value: ${err instanceof Error ? err.message : String(err)}`,
+        `Failed to decrypt encrypted column value (tenantId=${tenantId ? `'${tenantId}'` : '<empty>'}): ${err instanceof Error ? err.message : String(err)}`,
         { cause: err }
       );
     }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@framework/core/src/persistence/encryptedType.ts` around lines 209 - 217, The
decryption catch block around _encryptor.decrypt(value, tenantId) should include
the tenant context to aid debugging; update the thrown Error message in the
catch to incorporate the tenantId (from getCurrentTenantId()) and relevant
context (e.g., `tenantId: ${tenantId}`) so failures clearly show which tenant
(including empty string) was used when decrypting in encryptedType.ts; keep the
existing error cause (err) intact when constructing the new Error.

framework/infrastructure/redis/index.ts (2)

94-96: ⚠️ Potential issue | 🟠 Major

Don't let encrypted hits bypass tenant context.

decryptValue() returns before checking isEncrypted(), so a missed compliance propagation turns an encrypted Redis value into a bogus cache hit instead of an unreadable/miss path.

🐛 Proposed fix

  private decryptValue(value: string, compliance?: ComplianceContext): string {
-    if (!compliance || !this.encryptor) return value;
+    if (!this.encryptor) return value;
     if (!isEncrypted(value)) return value;
+    if (!compliance) {
+      throw new Error(
+        'Redis: compliance context is required for encrypted values'
+      );
+    }
     // If a value is encrypted but we cannot decrypt it, treat the entry as
     // unreadable rather than returning the ciphertext. Returning the raw

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@framework/infrastructure/redis/index.ts` around lines 94 - 96, decryptValue
currently early-returns when compliance or this.encryptor is missing before
checking isEncrypted, allowing encrypted blobs to be treated as valid plaintext;
change the logic in decryptValue to check isEncrypted(value) first and, if the
value is encrypted but compliance or this.encryptor is absent, do not return the
encrypted string as a hit—instead surface an unreadable/miss signal (e.g.,
return null/undefined or throw a RecoverableDecryptionError) so callers treat it
as a cache miss; if the value is encrypted and prerequisites exist, proceed to
decrypt normally using this.encryptor and ComplianceContext.

---

329-337: ⚠️ Potential issue | 🟡 Minor

Tighten the queue peek edge cases.

peekQueueRecord() still returns null as T on an empty list, and peekQueueRecords(..., 0, ...) expands to LRANGE 0 -1, i.e. the entire queue. The generic .filter(Boolean) also drops valid false/0 payloads.

🐛 Proposed fix

  async peekQueueRecord<T>(
    queueName: string,
    compliance?: ComplianceContext
  ): Promise<T> {
     // Queues use lPush + rPop, so the next item to dequeue lives at the
     // tail of the list, not the head. Reading lRange(0, 0) would return the
     // most-recently-pushed item — the opposite of dequeue order.
-    const value = await this.client.lRange(queueName, -1, -1);
-    return this.parseValue<T>(value[0], compliance);
+    const [value] = await this.client.lRange(queueName, -1, -1);
+    if (value === undefined) {
+      throw new Error(`Queue is empty: ${queueName}`);
+    }
+    return this.parseValue<T>(value, compliance);
  }

  async peekQueueRecords<T>(
    queueName: string,
    pageSize: number,
    compliance?: ComplianceContext
  ): Promise<T[]> {
+    if (pageSize <= 0) return [];
     // Tail-relative range: the last `pageSize` items, where the very last
     // item is the next to be dequeued. Redis returns them in list order
     // (oldest-tail-end first), so reverse to put next-to-dequeue first.
     const values = await this.client.lRange(queueName, -pageSize, -1);
     if (values.length === 0) return [];
-    return values
-      .reverse()
-      .map((value) => this.parseValue<T>(value, compliance))
-      .filter(Boolean);
+    return values.reverse().flatMap((value) => {
+      const parsed = this.parseValue<T>(value, compliance);
+      return parsed == null ? [] : [parsed];
+    });
  }

Also applies to: 340-353

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@framework/infrastructure/redis/index.ts` around lines 329 - 337,
peekQueueRecord and peekQueueRecords have edge cases: peekQueueRecord returns
null when lRange returns empty without explicit check, peekQueueRecords expands
a count of 0 into LRANGE 0 -1 and uses .filter(Boolean) which drops valid falsy
payloads. Fixes: in peekQueueRecord (function peekQueueRecord) explicitly check
if the lRange result array is empty and return null (or undefined per API)
before calling parseValue; in peekQueueRecords compute the LRANGE bounds so
count===0 immediately returns an empty array, and when building the parsed list
avoid .filter(Boolean) — use a filter that only removes null/undefined (e.g. x
=> x !== null && x !== undefined) so values like 0 or false are preserved; also
ensure LRANGE uses negative start indices (e.g. -count) or correctly clamps to
list length to avoid the 0 -> -1 whole-list expansion.

blueprint/implementations/billing/stripe/domain/schemas/zod/plan.schema.ts (1)

20-21: Duplicate PlanOmissions type definition.

Similar to SubscriptionOmissions, this duplicates the definition from stripe.dto.types.ts (line 203). Consider exporting and reusing it.

 import {
   StripePlanCreateParams,
   StripePlanUpdateParams,
-  StripeProduct
+  StripeProduct,
+  PlanOmissions
 } from '../../types/stripe.dto.types';

-type PlanOmissions = 'product' | 'interval' | 'currency';

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@blueprint/implementations/billing/stripe/domain/schemas/zod/plan.schema.ts`
around lines 20 - 21, The PlanOmissions type is duplicated here; remove this
local declaration of PlanOmissions and instead import and reuse the shared type
from stripe.dto.types.ts (where SubscriptionOmissions/PlanOmissions is defined),
updating the exports if necessary so plan.schema.ts references the single
exported type; ensure you replace the local "PlanOmissions" declaration with an
import statement and adjust any uses in plan.schema.ts to reference the imported
symbol.

blueprint/implementations/billing/stripe/domain/schemas/zod/subscription.schema.ts (1)

17-18: Duplicate SubscriptionOmissions type definition.

The SubscriptionOmissions type is identical to the one defined in stripe.dto.types.ts (line 245). Consider exporting and importing it from there to ensure they stay in sync and reduce duplication.

 import {
   StripeSubscription,
   StripeSubscriptionCreateParams,
-  StripeSubscriptionUpdateParams
+  StripeSubscriptionUpdateParams,
+  SubscriptionOmissions
 } from '../../types/stripe.dto.types';

-type SubscriptionOmissions = 'items' | 'customer';

Note: This requires exporting SubscriptionOmissions from stripe.dto.types.ts.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@blueprint/implementations/billing/stripe/domain/schemas/zod/subscription.schema.ts`
around lines 17 - 18, The file defines a duplicate type SubscriptionOmissions
that is already declared in stripe.dto.types.ts; remove the local definition and
import the shared type instead: export SubscriptionOmissions from
stripe.dto.types.ts (add the export there if missing) and replace the local
declaration with an import of SubscriptionOmissions in subscription.schema.ts so
both modules reference the same symbol.

blueprint/billing-stripe/persistence/entities/subscription.entity.ts (1)

1-5: Import ordering could be improved for consistency.

The imports are functional but could follow the 7-layer organization more strictly. Consider grouping @forklaunch/core/persistence with @forklaunch/blueprint-core as framework packages.

 import { sqlBaseProperties } from '@forklaunch/blueprint-core';
+import { defineComplianceEntity, fp } from '@forklaunch/core/persistence';
 import { BillingProviderEnum } from '@forklaunch/implementation-billing-stripe/enum';
 import { StripeSubscription } from '@forklaunch/implementation-billing-stripe/types';
-import { defineComplianceEntity, fp } from '@forklaunch/core/persistence';
 import { PartyEnum } from '../../domain/enum/party.enum';

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@blueprint/billing-stripe/persistence/entities/subscription.entity.ts` around
lines 1 - 5, Reorder the import statements to follow the 7-layer convention by
grouping framework packages together: place imports from
'@forklaunch/core/persistence' (defineComplianceEntity, fp) and
'@forklaunch/blueprint-core' (sqlBaseProperties) adjacent, then
third-party/implementation imports like
'@forklaunch/implementation-billing-stripe' (BillingProviderEnum,
StripeSubscription), and finally local project enums like PartyEnum; adjust the
current import order so sqlBaseProperties and defineComplianceEntity/fp are next
to each other to improve consistency.