Saltar al contenido principal

Consideraciones para la Migración

Situación actual​

La app envía las requests pendientes una por una desde el cliente. El servidor las procesa como requests HTTP individuales normales.

Objetivo​

Enviar la cola completa (o un batch) al servidor en un solo request, y que el servidor itere sobre las operaciones pendientes.

Datos que el servidor necesita por operación​

Cada item del batch debe contener:

{
  id: number;              // ID de transacción (para reportar resultado por operación)
  api: string;             // endpoint destino (ej: "/scouting/scout")
  method: string;          // "POST" | "PUT" | "PATCH" | "DELETE"
  body: string | object;   // payload de la operación
  params: object;          // query params (ej: { uuid: "..." })
  headers: {               // solo Content-Type y X-Version (Authorization la pone el server)
    "Content-Type": string;
    "X-Version": string;
  };
  userId: string;          // para multi-user / workspace
  date: number;            // timestamp de creación (para ordenamiento y TTL)
  sender: string;          // dominio de origen (para que el server respete orden)
}

Puntos críticos a resolver​

1. Orden de ejecución​

El servidor debe respetar el orden FIFO por sender y la jerarquía entre senders (field primero, luego el resto). Opciones:

  • Enviar ya ordenado desde el cliente (más simple).
  • Enviar con metadata de jerarquía y que el server ordene.

2. PUTF (upload de archivos)​

Las operaciones PUTF leen un archivo del filesystem local del dispositivo. No se pueden enviar como JSON plano. Opciones:

  • Excluir PUTF del batch y seguir enviándolas individualmente.
  • Convertir a base64 e incluir en el payload (costoso en tamaño).
  • Enviar como multipart con las imágenes adjuntas.

3. Respuesta parcial​

Si el batch tiene 20 operaciones y la #5 falla con 400, ¿qué pasa con las siguientes? El servidor debe devolver un resultado por operación:

{
  "results": [
    { "id": 1, "status": "ok" },
    { "id": 2, "status": "ok" },
    { "id": 5, "status": "error", "code": 400, "error": { "code": -6, "info": "..." } },
    { "id": 6, "status": "ok" },
    ...
  ]
}

4. Idempotencia​

Muchas operaciones usan UUIDs generados en el cliente (v1). Si el batch se reenvía por timeout, el servidor debe manejar duplicados (ya existe lógica para DUPLICATED_KEY = -6).

5. Authorization​

Actualmente el token se inyecta al momento de enviar. En el batch, el servidor debería usar el token del request principal (el POST del batch) para autenticar todas las operaciones internas.

6. Requests con tokens de apps externas​

Algunas requests (SDK tracking, marketplace storage) usan tokens de apps (headerService.jsonToken(token)). Estas necesitan un campo extra appToken o deben excluirse del batch.

7. Endpoint existente: /sync_pending​

Ya existe un endpoint que recibe el snapshot completo de las colas. Se podría extender este endpoint o crear uno nuevo para el batch de ejecución.

Propuesta de interface para el batch​

interface SyncBatchRequest {
  operations: Array<SyncOperation>;
  userId: string;
  timestamp: number;
}

interface SyncOperation {
  id: number;                    // transactionId
  sender: string;                // dominio
  senderHierarchy: number;       // jerarquía del sender
  api: string;                   // endpoint
  method: 'POST' | 'PUT' | 'PATCH' | 'DELETE';
  contentType: string;           // "application/json" | "application/x-www-form-urlencoded"
  body: string;                  // payload serializado
  params: { [key: string]: any };
  date: number;                  // timestamp de creación
  appToken?: string;             // solo para requests de apps externas
}

interface SyncBatchResponse {
  results: Array<{
    id: number;
    status: 'ok' | 'error' | 'skipped';
    httpStatus?: number;
    error?: { code: number; info: string };
  }>;
}

Qué queda en el cliente​

  • Formatear la cola al formato SyncBatchRequest.
  • Enviar un solo POST.
  • Procesar la respuesta: eliminar las exitosas, marcar errores, mover a removedQueue las que correspondan.
  • Mantener la UI de sync (progreso, errores, eliminados) adaptada al nuevo flujo.