Ir al contenido

Troubleshooting de staff

Esta página resuelve los problemas operativos más frecuentes del staff EMA Health. Si no encuentras tu caso, escribe en #emavault Slack.

”Credenciales inválidas” / “Continue with Google” no funciona

Sección titulada «”Credenciales inválidas” / “Continue with Google” no funciona»
  • Verifica que estás usando tu correo @emahealth.io (no personal).
  • Cierra sesión de Google y vuelve a entrar.
  • Probar en incógnito.

”NO_VAULT_USER” después de Google login

Sección titulada «”NO_VAULT_USER” después de Google login»

Tu Google login funcionó pero no estás en vault_users.

  • Pídele a un admin que te cree (ver getting-started).
  • Refresh y vuelve a loguear.

Tu user existe pero is_active=false. Admin tiene que reactivarte.

Causa: tu rol no tiene can_read=true en vault_permissions para ese módulo.

Solución:

  • Verifica con admin si tu rol debería tener acceso.
  • Admin actualiza vault_permissions o cambia tu rol.

Causa: tu rol filtró los items via canRead().

  • Verifica tu rol en Equipo Vault → tu usuario.
  • Admin ajusta permisos si corresponde.
  1. Ver el error específico en la response (UI muestra cuál step falló).
  2. Ir a Audit log filter por table=tenants action=UPDATE user=tú.
  3. Identificar la causa raíz:
    • Aidbox unreachable → problema infra.
    • Producto X retornó 503 → ese producto está caído.
    • X-Platform-Key inválido → admin re-rota con producto destino.
    • Slug duplicado → cambiar slug.
  4. Re-correr Provisionar productos con los products que faltan. El proceso es idempotente, no duplica recursos.

Causa probable: provisioning incompleto.

  • Verifica emashared.tenant_products para el tenant_id.
  • Si no hay row para ese product, falta el provisioning.
  • Re-correr provisioning desde Vault.

Verificar:

  1. Cron activado en CF dashboard.
  2. GITHUB_TOKEN válido y con scope repo.
  3. Logs Worker muestran [cron] github-sync ejecutando.
  4. Webhook configurado en GitHub repo settings (alternativa al cron).

Causas:

  • ANTHROPIC_API_KEY mal configurado → 500.
  • Anthropic API caído → 503 de upstream.
  • Lead sin contexto suficiente → Sonnet retorna texto genérico.
  • Rate limit Anthropic → esperar.

Solución:

  • Refresh la página y reintentar.
  • Si sigue fallando, escalar a admin que verifica ANTHROPIC_API_KEY.
  • En último caso, escribir la propuesta a mano (siempre opción).

EMI proxy retorna 503 en mi producto cliente

Sección titulada «EMI proxy retorna 503 en mi producto cliente»

Causas:

  1. EMI Worker caído → check https://emi.emahealth.io/api/health.
  2. tenant_emi_access.is_active=false → admin lo desactivó.
  3. emi_apps.{product} no está en ga → sigue alpha.
  4. Rate limit EMI Worker excedido → esperar.

Diagnóstico: GET /api/emi/access retorna razón.

Causas:

  • EMAWELL_* secrets faltantes → admin agrega en Worker.
  • Ema Well Supabase caído → check yvfxhrnghajwblyqtoel health.
  • service_role key incorrecta → admin verifica.

Causa: alguien hardcodeó hex en componente.

  • NO modifiques el componente en producción sin admin.
  • Reportar en #emavault con screenshot.
  • Solución correcta: usar [data-theme="dark"] CSS rule global.

Causa: el slug es distinto al nombre, o el cliente está archivado.

  • Buscar por slug exacto.
  • Filtrar Tenants por status=archived para ver inactivos.
  • Si no encuentras, admin verifica DB.

”Cannot connect to Supabase” en Dashboard

Sección titulada «”Cannot connect to Supabase” en Dashboard»

Causa probable: Supabase emahub caído.

  • Check status.supabase.com.
  • Esperar.
  • Si dura más de 1h, escalar a admin.

Causas:

  • Email mal escrito al invitar → corregir y re-invitar.
  • Loops API key inválida → admin verifica.
  • Email en spam del cliente → verificar con cliente.

Solución: re-enviar desde TenantDetail → tab Productos → click en producto → Resend invite.

Causa: la tabla creció demasiado o hay query lento.

  • Aplicar filtros (user, table, date range) para reducir scope.
  • Si sigue lento, admin DB considera particionar.
Sección titulada «Modificar precio de un servicio del catálogo»
  1. Ir a Catálogo → click en el servicio.
  2. Click Editar precios.
  3. Cambiar base_price_clp.
  4. Si tiene pricing_quotes activas, sistema te avisa cuántas usan este precio.
  5. Click Guardar → audit_log registra.

Si nada de lo anterior aplica:

  1. Reproducir el bug.
  2. Tomar screenshot.
  3. DevTools → Console → screenshot también.
  4. Postear en #emavault Slack:
    • Pasos para reproducir.
    • Screenshots.
    • Hora aprox.
    • Tu rol.