crowd-funder-for-time-pwa/docs/migration-testing/ENDORSERSERVER_PRE_MIGRATION_AUDIT.md

endorserServer.ts Pre-Migration Audit

Service Overview

• File: src/libs/endorserServer.ts
• Purpose: Endorser server interface and utilities for claims, contacts, and server communication
• Complexity: High (1510 lines)
• Migration Priority: High (Services category)

Current State Analysis

Phase 1: Database Migration Assessment

• Status: ⏳ NEEDS MIGRATION
• Issues Found:
  • Uses logConsoleAndDb from ../db/databaseUtil (line 31, 443)
  • Uses PlatformServiceFactory.getInstance() for database operations (line 1455)
  • Raw SQL query: "UPDATE contacts SET seesMe = ? WHERE did = ?" (line 1458)

Phase 2: SQL Abstraction Assessment

• Status: ⏳ NEEDS MIGRATION
• Issues Found:
  • Raw SQL query in setVisibilityUtil function (line 1458)
  • Direct database operation without service abstraction

Phase 3: Notification Migration Assessment

• Status: ⏳ NEEDS MIGRATION
• Issues Found:
  • Direct $notify calls in getHeaders function (line 405)
  • Hardcoded notification messages and timeouts
  • No notification helpers or constants used

Phase 4: Template Streamlining Assessment

• Status: ✅ NOT NEEDED
• Evidence: No template code found (service file)
• Actions Required: None

Technical Analysis

Database Operations

// Legacy databaseUtil usage
import { logConsoleAndDb } from "../db/databaseUtil";
logConsoleAndDb("Something failed in getHeaders call...", true);

// PlatformServiceFactory usage
const platformService = PlatformServiceFactory.getInstance();
await platformService.dbExec(
  "UPDATE contacts SET seesMe = ? WHERE did = ?",
  [visibility, contact.did],
);

Notification Operations

// Direct $notify calls
$notify(
  {
    group: "alert",
    type: "danger",
    title: "Personal Data Error",
    text: notifyMessage,
  },
  3000,
);

Code Complexity

• Lines: 1510 lines
• Functions: 40+ exported functions
• Imports: 15+ imports including legacy patterns
• Database Operations: 1 raw SQL query
• Notification Usage: Direct $notify calls

Key Functions Requiring Migration

1. getHeaders (line 405): Notification migration needed
2. setVisibilityUtil (line 1436): Database and SQL migration needed
3. logConsoleAndDb usage (line 443): Database migration needed

Migration Plan

Phase 1: Database Migration

1. Replace Legacy Imports

   • Remove logConsoleAndDb import
   • Replace with logger utilities

2. Update Database Operations

   • Replace PlatformServiceFactory.getInstance() with service injection
   • Update setVisibilityUtil to use service methods

Phase 2: SQL Abstraction

1. Replace Raw SQL
   • Extract contact visibility update to service method
   • Replace raw SQL with service call

Phase 3: Notification Migration

1. Add Notification Helpers

   • Import notification constants and helpers
   • Replace direct $notify calls with helper methods
   • Use notification constants for messages

2. Update Notification Patterns

   • Extract notification messages to constants
   • Use timeout constants instead of hardcoded values

Estimated Migration Time

• Phase 1: 10-15 minutes
• Phase 2: 5-10 minutes
• Phase 3: 10-15 minutes
• Total Time: 25-40 minutes

Risk Assessment

• Medium Risk: Large service file with multiple migration points
• Breaking Changes: Database and notification pattern changes
• Performance Impact: Minimal (service modernization)

Success Criteria

• Legacy databaseUtil imports removed
• PlatformServiceFactory usage replaced with service injection
• Raw SQL query replaced with service method
• Direct $notify calls replaced with helper methods
• Notification constants used for messages
• Linting passes with no errors
• Service functionality preserved

Migration Notes

• Large service file requiring careful migration
• Multiple functions need database and notification updates
• Service is critical for server communication
• Need to maintain backward compatibility during migration

---

Audit Date: 2024-12-19 Auditor: Migration System Status: Ready for Phase 1, 2, & 3 migration