Skip to content

Conversation

@coodos
Copy link
Contributor

@coodos coodos commented Nov 14, 2025

Description of change

Issue Number

Type of change

  • Fix (a change which fixes an issue)

How the change has been tested

Change checklist

  • I have ensured that the CI Checks pass locally
  • I have removed any unnecessary logic
  • My code is well documented
  • I have signed my commits
  • My code follows the pattern of the application
  • I have self reviewed my code

Summary by CodeRabbit

Release Notes

  • New Features

    • Added AI-powered charter summarization for better charter management visibility
    • Added support for charter descriptions and improved chat sorting
    • Enhanced Cerberus detection with multi-path recognition strategy
  • Improvements

    • Improved vault access control for resource creation workflows
    • Optimized initial data synchronization in watchers
    • Enhanced webhook group handling with partial updates and better admin management
    • Streamlined eVault provisioning when adding charters
  • Bug Fixes

    • Fixed access control to allow resolver-driven envelope creation for non-existent resources
  • Other Changes

    • Updated ontology references; adjusted default group charter status

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Nov 14, 2025

Caution

Review failed

The pull request is closed.

Walkthrough

This PR refactors W3ID resolution to use vault.ename directly instead of key service lookups, updates vault access guard with new creation pathways, enhances Cerberus detection with multi-fallback strategies and AI-driven charter summarization, renames signing service classes for clarity, introduces eVault auto-provisioning in GroupController, and refactors webhook handling with partial-update semantics and improved Firestore watcher state tracking.

Changes

Cohort / File(s) Summary
W3ID Resolution Refactoring
infrastructure/eid-wallet/src/routes/(app)/scan-qr/scanLogic.ts
Replaced key service getPublicKey calls with direct vault.ename usage in three code paths (handleAuth, handleSignVote, blind vote); removed w3id field from authPayload and signedPayload; eliminated related console logging and debug output.
Vault Access Guard
infrastructure/evault-core/src/core/protocol/vault-access-guard.ts
Added new creation/update pathway: when targeting non-existent envelope with input data, directly invoke resolver and return ACL-filtered result instead of enforcing access denial first.
Ontology Reference Update
infrastructure/web3-adapter/src/index.ts
Updated GraphQL mutation ontology ID for GroupManifest storage from 550e8400-e29b-41d4-a716-446655440001 to 550e8400-e29b-41d4-a716-446655440003.
Firestore Watcher State Management
platforms/blabsy-w3ds-auth-api/src/web3adapter/watchers/firestoreWatcher.ts
Added watcherStartTime and firstSnapshotReceived tracking; introduced processChanges method; updated first-snapshot handling to filter documents by updatedAt/createdAt timestamps and process only recent changes.
Chat Context
platforms/blabsy/src/lib/context/chat-context.tsx
Enhanced sorting logic with null-safe fallback chain (updatedAt → createdAt); expanded createNewChat signature to accept optional description parameter.
Cerberus Webhook Handling
platforms/cerberus/src/controllers/WebhookController.ts
Introduced partial-update semantics for groups (only update present fields); added explicit localId/globalId logging; enhanced admin/participants parsing with null filtering; reworked new-group creation to check for existing ename before creating; added conditional charter welcome flow; normalized isSystemMessage checks for messages.
Group Configuration
platforms/cerberus/src/database/entities/Group.ts
Changed isCharterActive default column value from true to false.
Cerberus Field Mappings
platforms/cerberus/src/web3adapter/mappings/group.mapping.json, platforms/cerberus/src/web3adapter/mappings/message.mapping.json
Updated group.mapping.json: ename field maps to eName; updated message.mapping.json: added isSystemMessage field mapping.
Cerberus Message Subscriber
platforms/cerberus/src/web3adapter/watchers/subscriber.ts
Removed logging for skipped non-system messages; added detailed system message logging (data keys, sender, group ID, text excerpt, isSystemMessage flag); added envelope response logging after change handling.
Cerberus Trigger Service
platforms/cerberus/src/services/CerberusTriggerService.ts
Enhanced isCerberusEnabled with multi-fallback detection strategy (markdown formatting, single-line check, three progressive fallbacks); reworked processCharterChange with 10-second delays, Cerberus availability notifications for non-enabled charters, dynamic OpenAI integration for charter summarization, and differentiated messaging for created vs. updated/removed charters.
OpenAI Integration
platforms/cerberus/src/services/OpenAIService.ts
Added new public method summarizeCharter(charterText): Promise to generate AI-driven charter summaries via GPT-4 with fallback handling.
Charter Signing Service Refactor
platforms/group-charter-manager-api/src/services/SigningSessionService.ts
Renamed class CharterSigningService → SigningSessionService; renamed interfaces CharterSigningSession → SigningSession and SignedCharterPayload → SigningResult; updated all method return types and internal references accordingly.
Charter Signing Controller
platforms/group-charter-manager-api/src/controllers/CharterSigningController.ts
Replaced CharterSigningService with SigningSessionService; added public methods (testConnection, createSigningSession, getSigningSessionStatus, handleSignedPayload, getSigningSession); updated payload handling to use w3id instead of publicKey.
GroupController eVault Provisioning
platforms/group-charter-manager-api/src/controllers/GroupController.ts
Added dotenv initialization; added updateCharter flow: when charterless group lacks ename, auto-provision eVault with spinUpEVault and assign resulting w3id to ename; validates PUBLIC_REGISTRY_URL and PUBLIC_PROVISIONER_URL environment variables.
Group Subscriber eVault Removal
platforms/group-charter-manager-api/src/web3adapter/watchers/subscriber.ts
Removed eVault creation flow: deleted createGroupEVault import, spinUpGroupEVault method, and related async invocation during afterUpdate; simplified afterUpdate to directly enrich fullEntity.
Charter Signature Service
platforms/group-charter-manager-api/src/services/CharterSignatureService.ts
Whitespace and formatting changes only; no logic or API changes.

Sequence Diagram(s)

sequenceDiagram
    participant Client
    participant ScanLogic
    participant Vault
    participant KeyService as Key Service<br/>(old)

    rect rgb(200, 220, 240)
    Note over Client,KeyService: OLD: W3ID via Key Service
    Client->>ScanLogic: handleAuth()
    ScanLogic->>KeyService: getPublicKey()
    KeyService-->>ScanLogic: w3id
    ScanLogic->>ScanLogic: add w3id to authPayload
    ScanLogic-->>Client: authPayload with w3id
    end

    rect rgb(220, 240, 220)
    Note over Client,Vault: NEW: Direct vault.ename
    Client->>ScanLogic: handleAuth()
    ScanLogic->>Vault: check vault.ename
    Vault-->>ScanLogic: ename value
    ScanLogic->>ScanLogic: ename ? proceed : skip
    ScanLogic-->>Client: authPayload (no w3id field)
    end
Loading
sequenceDiagram
    participant Webhook as Webhook<br/>Request
    participant Controller as Webhook<br/>Controller
    participant Cerberus as Cerberus<br/>Service
    participant OpenAI as OpenAI<br/>Service
    participant DB as Database

    rect rgb(240, 220, 200)
    Note over Webhook,DB: Charter Created Workflow
    Webhook->>Controller: POST webhook (charter event)
    Controller->>Cerberus: isCerberusEnabled(charter)
    Cerberus-->>Controller: false (not enabled)
    Controller->>Controller: wait 10s
    Controller->>Cerberus: sendAvailabilityNotification()
    Cerberus-->>Controller: notification sent
    Controller-->>Webhook: 200 OK
    end

    rect rgb(220, 240, 220)
    Note over Webhook,DB: Charter Created + Cerberus Enabled
    Webhook->>Controller: POST webhook (charter event)
    Controller->>Cerberus: isCerberusEnabled(charter)
    Cerberus-->>Controller: true
    Controller->>Controller: wait 10s
    Controller->>OpenAI: summarizeCharter(charterText)
    OpenAI->>OpenAI: GPT-4 summarization
    OpenAI-->>Controller: CharterChangeSummary
    Controller->>Cerberus: analyzeCharterViolations()
    Cerberus-->>Controller: analysis result
    Controller->>DB: createSystemMessage(welcomeMsg)
    DB-->>Controller: created
    Controller-->>Webhook: 200 OK
    end
Loading
sequenceDiagram
    participant Client
    participant GroupController as GroupController
    participant GroupService
    participant Provisioner as spinUpEVault
    participant DB as Database

    rect rgb(240, 240, 220)
    Note over Client,DB: Charter Add to Charterless Group
    Client->>GroupController: PATCH /group/:id<br/>(add charter)
    alt group.ename exists
        GroupController->>GroupService: updateGroup(id, {charter})
        GroupService->>DB: update only charter
    else group lacks both charter and ename
        GroupController->>Provisioner: spinUpEVault(registryUrl,<br/>provisionerUrl, demoCode)
        Provisioner-->>GroupController: {w3id}
        GroupController->>GroupService: updateGroup(id,<br/>{charter, ename: w3id})
        GroupService->>DB: update charter + ename
    end
    GroupService-->>GroupController: updated
    GroupController-->>Client: 200 OK
    end
Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Areas requiring extra attention:

  • CerberusTriggerService.isCerberusEnabled: Multi-fallback detection logic with three fallback strategies requires validation of regex patterns and markdown parsing correctness
  • CerberusTriggerService.processCharterChange: Complex branching with 10-second delays, OpenAI integration, and differentiated messaging paths (created vs. updated/removed); verify async handling and error paths
  • WebhookController charter/group handling: Partial-update semantics with conditional field updates; verify that optional fields are correctly preserved and not overwritten
  • GroupController eVault provisioning: Environment variable validation and spinUpEVault integration; ensure error handling if provisioning fails or URLs are misconfigured
  • CharterSigningController refactoring: Full service replacement with new method signatures; verify all call sites properly use w3id instead of publicKey
  • FirestoreWatcher timestamp filtering: Logic for filtering documents by updatedAt/createdAt on first snapshot; ensure timestamp comparisons and null checks are correct

Possibly related PRs

  • Fix/group charter issues #426: Shares identical code-level changes in infrastructure/eid-wallet/src/routes/(app)/scan-qr/scanLogic.ts (replacing getPublicKey/W3ID retrieval with vault.ename and removing w3id logging)
  • Chore/evault pitstop refactor #395: Related refactor switching to vault.ename directly, removing getPublicKey lookups that introduced eName/w3id resolution surfaces touched by evault refactor
  • feat: chat pagination #378: Modifies platforms/blabsy/src/lib/context/chat-context.tsx to adjust chat sorting logic (same module touched by main PR's createNewChat description parameter)

Suggested reviewers

  • sosweetham
  • xPathin

Poem

🐰 Hoppy refactoring times ahead,
eVault names spring forth instead,
Cerberus now sees with AI's might,
Signing sessions made more light.
Charter summaries take their flight!

Pre-merge checks and finishing touches

❌ Failed checks (2 warnings, 1 inconclusive)
Check name Status Explanation Resolution
Description check ⚠️ Warning The description follows the template structure with type of change marked as 'Fix', but critical sections are incomplete: Issue Number is empty, How the change has been tested is empty, and all checklist items are unchecked. Complete the description by filling in the Issue Number, describing how changes were tested, and checking the applicable checklist items to confirm compliance with project standards.
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
Title check ❓ Inconclusive The title 'Fix/group charter issues' is related to the changeset but is vague and generic, using non-descriptive terms that don't convey the specific nature of the fixes across multiple components. Replace with a more specific title that highlights the primary fix, e.g., 'Refactor signing session management and improve charter provisioning' or focus on the main issue being addressed.

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 53f037c and d436f76.

📒 Files selected for processing (1)
  • infrastructure/web3-adapter/src/index.ts (1 hunks)

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 6

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (2)
platforms/blabsy/src/lib/context/chat-context.tsx (2)

35-35: Critical: Type definition missing description parameter.

The type definition for createNewChat doesn't include the description parameter that was added to the implementation (lines 180-184). This creates a TypeScript type mismatch that will prevent callers from passing the description parameter.

Apply this diff to fix the type definition:

-    createNewChat: (participants: string[], name?: string) => Promise<string>;
+    createNewChat: (participants: string[], name?: string, description?: string) => Promise<string>;

180-201: Update the ChatContext interface type to match the createNewChat implementation signature.

The type definition at line 35 is missing the description parameter that was added to the implementation:

Current interface (line 35):

createNewChat: (participants: string[], name?: string) => Promise<string>;

Should be:

createNewChat: (participants: string[], name?: string, description?: string) => Promise<string>;

The implementation now accepts description as an optional parameter (lines 180-183), but the interface contract hasn't been updated. This creates a type mismatch and prevents TypeScript consumers from passing the description parameter.

🧹 Nitpick comments (11)
infrastructure/eid-wallet/src/routes/(app)/scan-qr/scanLogic.ts (1)

656-677: Simplify redundant error handling.

Since w3idResult is now directly assigned from vault.ename at line 667, the try-catch block (lines 657-677) and the fallback at line 676 are redundant. The code will either succeed with vault.ename or fail if vault is not available (already handled by the check at lines 651-654).

Apply this diff to simplify the code:

-            let voterPublicKey: string;
-            try {
-                const { created } = await globalState.keyService.ensureKey(
-                    vault.ename,
-                    "signing",
-                );
-                console.log(
-                    "Key generation result for blind voting:",
-                    created ? "key-generated" : "key-exists",
-                );
-
-                const w3idResult = vault.ename;
-                if (!w3idResult) {
-                    throw new Error("Failed to get W3ID");
-                }
-                voterPublicKey = w3idResult;
-
-                console.log("🔑 Voter W3ID retrieved:", voterPublicKey);
-            } catch (error) {
-                console.error("Failed to get W3ID using KeyManager:", error);
-                voterPublicKey = vault.ename || "unknown_public_key";
-            }
+            // Ensure signing key exists for this vault
+            const { created } = await globalState.keyService.ensureKey(
+                vault.ename,
+                "signing",
+            );
+            console.log(
+                "Key generation result for blind voting:",
+                created ? "key-generated" : "key-exists",
+            );
+
+            const voterPublicKey = vault.ename;
+            if (!voterPublicKey) {
+                throw new Error("Failed to get W3ID: vault.ename is not available");
+            }
+            console.log("🔑 Voter W3ID retrieved:", voterPublicKey);
platforms/blabsy-w3ds-auth-api/src/web3adapter/watchers/firestoreWatcher.ts (1)

382-448: LGTM! Good refactor to extract change processing logic.

The processChanges() method effectively centralizes the document change processing logic, reducing duplication and improving maintainability. The implementation correctly handles:

  • Duplicate detection via processedIds and processingIds
  • Lock checking via adapter.lockedIds
  • Parallel processing with appropriate error handling
  • Cleanup of tracking sets on removal or error
platforms/cerberus/src/web3adapter/watchers/subscriber.ts (1)

210-233: Rich message/envelope logging is useful; consider gating and sensitivity

The new logs around message payloads and the envelope response are great for debugging system-message handling. Two things to keep in mind:

  • This logs data.sender, data.group, and a text excerpt; if those can contain user or group PII, it may be worth routing through your structured logger (with levels) and/or gating by environment.
  • If message volume grows, these console logs could become noisy in production.

Functionality-wise, the change is safe since it only runs after the existing system‑message check.

platforms/group-charter-manager-api/src/controllers/GroupController.ts (1)

4-8: Duplication of demo verification code confirmed across multiple platform services

The verification confirms the original concern: the demo code d66b7138-538a-465f-a6ce-f6985854c3f4 is hard-coded in at least four locations:

  • platforms/group-charter-manager-api/src/controllers/GroupController.ts:138 (under review)
  • platforms/dreamsync-api/src/services/PlatformEVaultService.ts:97
  • platforms/cerberus/src/services/PlatformEVaultService.ts:97
  • infrastructure/web3-adapter/src/index.ts:23, 104

While a centralized DEMO_CODE_W3DS environment variable pattern exists in test utilities and some core services, it is not consistently applied across all platform controllers. Extracting the constant to a shared location (either within web3-adapter as an export or via a consistently-applied environment variable across all platforms) would reduce maintenance burden and drift risk.

platforms/group-charter-manager-api/src/controllers/CharterSigningController.ts (1)

57-107: SSE status polling remains correct but keeps a long‑lived interval

The SSE endpoint correctly:

  • Validates sessionId,
  • Sends an initial status event,
  • Polls getSessionStatus every second and emits terminal events for completed, expired, security_violation, or missing sessions,
  • Clears the interval on completion or client disconnect.

This is structurally sound for low/moderate traffic; if this endpoint sees heavy use, you may later want to consider event‑driven notifications instead of 1s polling.

platforms/group-charter-manager-api/src/services/SigningSessionService.ts (2)

38-79: Session creation logic is sound but sessions are never pruned

createSession correctly:

  • Generates a sessionId,
  • Builds a QR payload with a redirect URI,
  • Stores a pending session,
  • Schedules a timeout to flip stale pending sessions to expired.

However, completed/expired sessions remain in this.sessions indefinitely. Under sustained usage this map can grow without bound.

Consider pruning entries (e.g., deleting sessions once they become expired/completed, or running a periodic cleanup) to keep memory usage bounded.


97-195: Signed payload processing and security check are consistent with new flow

processSignedPayload:

  • Loads the session via getSession,
  • Rejects missing or non‑pending sessions,
  • Ensures signature, publicKey (now effectively w3id), and message are present,
  • Verifies the provided identifier (after stripping @) matches user.ename (also normalized),
  • Marks sessions with mismatched identifiers as security_violation and returns a structured error,
  • Records signatures via CharterSignatureService.recordSignature,
  • Marks successful sessions completed and returns a SigningResult.

This matches how the controller uses it and how SSE interprets statuses. Aside from naming (publicKey vs the w3id semantics), behavior looks correct.

If you want to reduce confusion now that w3id is passed in, consider renaming publicKeyw3id (and the corresponding SigningResult field) in a follow‑up refactor.

platforms/cerberus/src/controllers/WebhookController.ts (2)

190-237: New-group creation by ename with charter-trigger looks reasonable but is synchronous

The new flow when localId is missing:

  • Optionally finds an existing group by ename and just stores the mapping if found.
  • Otherwise creates a new group with normalized admins/participants and charter, then:
    • Stores mapping,
    • If group.charter exists, awaits cerberusTriggerService.processCharterChange(...).

Functionally this is solid and avoids duplicate groups when ename is reused. The only concern is that processCharterChange now includes a 10‑second delay and OpenAI calls, so the webhook request will block on that work.

Consider running processCharterChange asynchronously (e.g., without await, or via a background job/queue) to keep webhook latency low while still triggering Cerberus behavior.


373-404: Charter signature creation, mapping, and activation analysis

For charter_signatures:

  • A new charter signature is created via charterSignatureService.createCharterSignature using normalized group/user IDs and payload fields.
  • The local/global mapping is stored and the signature ID is locked.
  • analyzeCharterActivation(group.id, this.messageService) is invoked to recompute charter activation and emit any status messages.

This is a good encapsulation of signature creation and downstream charter-state handling.

Please confirm that CharterSignatureService exposes a createCharterSignature({ data: ... }) method with the same data shape, and that analyzeCharterActivation is idempotent and safe to call on every new signature (it may call OpenAI and update group state).

platforms/cerberus/src/services/CerberusTriggerService.ts (2)

52-109: Expanded Cerberus enablement detection is permissive but coherent

isCerberusEnabled now:

  1. Looks for explicit “watchdog name” in markdown (multi‑line Watchdog Name:\n**cerberus**).
  2. Falls back to same‑line watchdog name: cerberus.
  3. Fallback 1: simple substring 'watchdog name: cerberus'.
  4. Fallback 2: “Automated Watchdog Policy” section mentioning Cerberus within ~500 chars.
  5. Fallback 3: presence of both watchdog and cerberus anywhere.

Given the goal of not missing legitimate Cerberus configurations, these fallbacks make sense, but Fallback 3 in particular will treat any charter that casually mentions both terms as “enabled”. If stricter semantics are desired, you might later tighten or remove that last fallback.


156-265: Charter-change processing adds rich flows but introduces deliberate delays

The new processCharterChange behavior:

  • Determines changeType (created/updated/removed).
  • Checks isCerberusEnabled(groupId):
    • If not enabled:
      • For created, waits 10s then sends a system message explaining how to enable Cerberus via “Watchdog Name: Cerberus”.
      • For other change types, simply returns.
    • If enabled:
      • Waits 10s.
      • For created:
        • Dynamically imports CharterSignatureService and OpenAIService.
        • Summarizes the charter, runs analyzeCharterActivation, and posts a detailed welcome message.
      • For updated/removed:
        • Posts a concise change message explaining implications.
  • For updated with both oldCharter and newCharter, still calls handleCharterTextChange for deeper invalidation and analysis.

Functionally this is a solid step up in UX and safety. The main trade‑off is that callers that await processCharterChange (e.g., the webhook controller) will now be blocked for at least 10 seconds plus OpenAI latency.

If webhook or HTTP response latency is a concern, consider not awaiting processCharterChange from request handlers (or moving the delay/AI work to a background job/queue), while keeping this richer charter‑change logic intact.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 01c09dc and 53f037c.

📒 Files selected for processing (18)
  • infrastructure/eid-wallet/src/routes/(app)/scan-qr/scanLogic.ts (3 hunks)
  • infrastructure/evault-core/src/core/db/db.service.ts (1 hunks)
  • infrastructure/evault-core/src/core/protocol/vault-access-guard.ts (1 hunks)
  • infrastructure/web3-adapter/src/index.ts (3 hunks)
  • platforms/blabsy-w3ds-auth-api/src/web3adapter/watchers/firestoreWatcher.ts (6 hunks)
  • platforms/blabsy/src/lib/context/chat-context.tsx (1 hunks)
  • platforms/cerberus/src/controllers/WebhookController.ts (8 hunks)
  • platforms/cerberus/src/database/entities/Group.ts (1 hunks)
  • platforms/cerberus/src/services/CerberusTriggerService.ts (2 hunks)
  • platforms/cerberus/src/services/OpenAIService.ts (1 hunks)
  • platforms/cerberus/src/web3adapter/mappings/group.mapping.json (1 hunks)
  • platforms/cerberus/src/web3adapter/mappings/message.mapping.json (1 hunks)
  • platforms/cerberus/src/web3adapter/watchers/subscriber.ts (1 hunks)
  • platforms/group-charter-manager-api/src/controllers/CharterSigningController.ts (7 hunks)
  • platforms/group-charter-manager-api/src/controllers/GroupController.ts (2 hunks)
  • platforms/group-charter-manager-api/src/services/CharterSignatureService.ts (4 hunks)
  • platforms/group-charter-manager-api/src/services/SigningSessionService.ts (11 hunks)
  • platforms/group-charter-manager-api/src/web3adapter/watchers/subscriber.ts (1 hunks)
🧰 Additional context used
🧬 Code graph analysis (5)
platforms/group-charter-manager-api/src/controllers/GroupController.ts (1)
infrastructure/web3-adapter/src/index.ts (2)
  • spinUpEVault (18-64)
  • spinUpEVault (415-432)
platforms/group-charter-manager-api/src/services/SigningSessionService.ts (1)
platforms/group-charter-manager-api/src/services/CharterSignatureService.ts (1)
  • CharterSignatureService (7-142)
platforms/cerberus/src/services/CerberusTriggerService.ts (2)
platforms/cerberus/src/services/CharterSignatureService.ts (1)
  • CharterSignatureService (8-287)
platforms/cerberus/src/services/OpenAIService.ts (1)
  • OpenAIService (18-296)
platforms/group-charter-manager-api/src/controllers/CharterSigningController.ts (1)
platforms/group-charter-manager-api/src/services/SigningSessionService.ts (1)
  • SigningSessionService (34-204)
infrastructure/web3-adapter/src/index.ts (4)
infrastructure/web3-adapter/src/mapper/mapper.types.ts (1)
  • IMapping (3-42)
infrastructure/web3-adapter/src/db/mapping.db.ts (1)
  • MappingDatabase (6-186)
infrastructure/web3-adapter/src/evault/evault.ts (1)
  • EVaultClient (131-618)
infrastructure/web3-adapter/src/mapper/mapper.ts (2)
  • toGlobal (238-356)
  • fromGlobal (123-208)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)
  • GitHub Check: build
  • GitHub Check: test-web3-adapter-integration
  • GitHub Check: test
  • GitHub Check: lint
  • GitHub Check: test
🔇 Additional comments (21)
platforms/blabsy/src/lib/context/chat-context.tsx (1)

120-133: Excellent null-safe sorting logic.

The enhanced sorting logic properly handles edge cases where updatedAt or createdAt might be null/undefined, with appropriate fallbacks at each level. This defensive approach prevents runtime errors and ensures deterministic behavior.

infrastructure/eid-wallet/src/routes/(app)/scan-qr/scanLogic.ts (1)

526-529: LGTM: Simplified W3ID resolution in signing flow.

The change to use vault.ename directly is consistent with the authentication flow. Note that despite the AI summary, the w3id field is still included in signedPayload at line 564, which maintains backward compatibility.

Also applies to: 564-566

infrastructure/evault-core/src/core/db/db.service.ts (1)

555-555: Remove the parsed field from updateMetaEnvelopeById return; do not add to storeMetaEnvelope.

The StoreMetaEnvelopeResult type definition explicitly defines metaEnvelope with only id, ontology, and acl fields—no parsed. The updateMetaEnvelopeById method at line 555 violates this type contract by adding parsed: meta.payload. Both methods should match the type definition; the fix is to remove parsed from updateMetaEnvelopeById, not add it to storeMetaEnvelope.

Likely an incorrect or invalid review comment.

platforms/blabsy-w3ds-auth-api/src/web3adapter/watchers/firestoreWatcher.ts (4)

21-22: LGTM! State tracking fields added.

The new fields watcherStartTime and firstSnapshotReceived properly support the first-snapshot filtering logic and are correctly reset in start(), reconnect(), and handleError().


62-64: LGTM! State correctly reset on start.

The watcher state is properly initialized before setting up the Firestore listener.


240-241: LGTM! Watcher state correctly reset on reconnection.

The state is properly reset in both reconnect() and handleError() paths, ensuring that first-snapshot filtering works correctly after re-establishing the listener.

Also applies to: 359-360


450-454: LGTM! Clean delegation to centralized change processing.

The refactored processSnapshot() method now properly delegates to processChanges(), maintaining a single responsibility and improving code clarity.

platforms/cerberus/src/database/entities/Group.ts (1)

37-38: Changing isCharterActive default to false only affects new groups

This will keep existing rows as-is and only make newly created groups start with an inactive charter. Please double-check that:

  • Any flow that should auto-activate a charter explicitly sets isCharterActive = true.
  • If you intend existing groups to become inactive until re‑evaluated, a DB migration or backfill is added elsewhere.
platforms/cerberus/src/web3adapter/mappings/message.mapping.json (1)

6-13: Adding isSystemMessage mapping looks consistent

Mapping isSystemMessageisSystemMessage matches how PostgresSubscriber.handleChange inspects/logs this flag for messages and keeps the schema symmetrical between local and global views.

platforms/cerberus/src/web3adapter/mappings/group.mapping.json (1)

6-18: enameeName mapping matches GroupManifest schema

Remapping the local ename field to the global eName key aligns this mapping with the GroupManifest shape in the web3-adapter and should make identity fields consistent across components.

platforms/group-charter-manager-api/src/services/CharterSignatureService.ts (1)

26-41: No functional changes in this diff block

The changes here appear to be whitespace/formatting only; the signature recording and lookup logic is unchanged.

infrastructure/web3-adapter/src/index.ts (1)

18-63: EVault spin-up helper is cohesive and error handling is reasonable

The standalone spinUpEVault function cleanly encapsulates entropy + provision calls, basic validation of the success flag, and Axios-aware error messages. This keeps the Web3Adapter and controller code simpler while centralizing the provisioning behavior.

platforms/cerberus/src/services/OpenAIService.ts (1)

95-147: summarizeCharter implementation is consistent and safely falls back

The new summarizeCharter method matches the existing OpenAI patterns here: clear instructions, low temperature, and a robust fallback CharterChangeSummary if the response is missing or not valid JSON. The return shape aligns with the CharterChangeSummary interface.

platforms/group-charter-manager-api/src/web3adapter/watchers/subscriber.ts (1)

222-235: No-op whitespace change in handleChange

The added blank line does not affect behavior; existing delayed handleChange flow remains intact.

platforms/group-charter-manager-api/src/controllers/CharterSigningController.ts (3)

2-22: Service rename to SigningSessionService looks consistent

Import, field type, constructor wiring, and ensureService all consistently use SigningSessionService; error messaging is updated and clear.


37-49: Improved validation message for session creation

The 400 response now clearly lists the required fields (groupId, charterData, userId), which should make client debugging easier. The rest of the flow (userId from req.user, delegation to createSession) is unchanged.


170-189: Session lookup endpoint is straightforward

getSigningSession validates sessionId, returns 404 when missing, and otherwise returns the session object from SigningSessionService. Behavior is consistent with the in‑memory session model.

platforms/group-charter-manager-api/src/services/SigningSessionService.ts (2)

4-36: Session and result typing matches controller usage

SigningSession and SigningResult interfaces align with how the controller and SSE endpoints consume session fields and status values (pending, completed, expired, security_violation). Typing of sessions: Map<string, SigningSession> and the injected CharterSignatureService is consistent.


197-203: getSessionStatus wrapper is minimal and appropriate

getSessionStatus simply delegates to getSession, preserving the expiration behavior there. No issues here.

platforms/cerberus/src/controllers/WebhookController.ts (2)

106-138: Improved group logging and admin parsing

  • Additional logs for global/local IDs will help trace group webhook flows.
  • Admin extraction now:
    • Starts from local.data.admins (default []),
    • Filters out null/undefined,
    • Normalizes relation strings to bare IDs.

This is a clear improvement over raw usage of admin refs.


257-269: System message detection handles both flag and text prefix

isSystemMessage now considers:

  • local.data.isSystemMessage === true, or
  • text starting with '$$system-message$$'.

Combined with the later logic that allows sender to be null only for system messages, this should correctly distinguish system vs non‑system messages coming from web3.

@ananyayaya129 ananyayaya129 merged commit ac398e7 into main Nov 14, 2025
5 of 7 checks passed
@ananyayaya129 ananyayaya129 deleted the fix/group-charter-issues branch November 14, 2025 05:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants