Cómo solucionar el error EINTEGRITY al desplegar una Aplicación de Múltiples Objetivos (MTA) en SAP Cloud Platform Cloud Foundry

Si estás utilizando NodeJS en tu proyecto (y es difícil no hacerlo), es posible que te encuentres atrapado en el infierno de EINTEGRITY. ¿Qué quiero decir con esto?

Cuando sucede:

Si estás implementando una Aplicación de Múltiples Objetivos (MTA) en SAP Cloud Platform Cloud Foundry, es posible que falle si hay una discrepancia en los archivos que estás enviando como parte de tu proyecto y el intento del sistema de extraer archivos dependientes adicionales durante la implementación. Esto puede ocurrir con despliegues completos donde todo el proyecto se comprime en un archivo .mtar, o despliegues parciales de módulos NodeJS individuales (incluidos el app-router y los módulos de base de datos HDI, que son aplicaciones NodeJS especializadas).

Cómo saber que está sucediendo:

Por lo general, verás que el módulo falla (al realizar un push) o que el despliegue completo intentará iniciar el módulo 3 veces antes de rendirse. Observa la salida y encuentra qué módulo está fallando. La salida predeterminada no te dará suficiente información para resolver esto. Necesitas inspeccionar los registros del módulo en sí.

cf logs failing-module --recent

Desplázate hacia atrás en la salida de registros buscando el mensaje "npm ERR! code EINTEGRITY". Aquí tienes una muestra de la salida.

        2020-07-06T19:40:39.05-0400 [STG/0] OUT --> Building dependencies
        2020-07-06T19:40:39.05-0400 [STG/0] OUT Installing node modules (package.json + package-lock.json)
        2020-07-06T19:41:00.45-0400 [STG/0] OUT npm ERR! code EINTEGRITY
        ...
    

Por qué está sucediendo:

Cuando tus archivos NodeJS se están preparando para un despliegue, la herramienta de empaquetado realizará un "npm install --production" en cada módulo de NodeJS para crear una carpeta node_modules con todas las dependencias (y dependencias de dependencias) enumeradas en el archivo package.json y un archivo package-lock.json que esté sincronizado con él. Todos los archivos se comprimen en el archivo .mtar y se envían para el despliegue.

Si ejecutas "npm install" dentro de un módulo único y haces manualmente "cf push", el efecto es similar, solo que hiciste la parte de "npm install" tú mismo.

Cuando el módulo es recibido por la plataforma en la nube y desplegado, el paquete de compilación de NodeJS analizará lo que se envió y buscará si se necesitan dependencias adicionales que no se enviaron.

¡AQUÍ ES DONDE OCURRE EL PROBLEMA!

Si se determina (y no estoy completamente seguro de qué desencadena esto) que el paquete de compilación necesita verificar las dependencias, leerá el archivo package-lock.json que enviaste y realizará una verificación de integridad generando un checksum en el paquete (el checksum but got ) que enviaste en node_modules O uno que determinó que necesitaba descargar del repositorio de paquetes del que quiere extraer y lo comparará con lo que se listaba en el archivo package-lock.json (el checksum wanted ). Si encuentra que no coinciden, obtendrás el error "npm ERR! code EINTEGRITY" y el despliegue/push fallará.

¿Qué puedes hacer al respecto?

Parece que la razón por la que esto ocurre se debe a algún problema que ocurre cuando el paquete se publica en el repositorio. El más mínimo error resultará en una discrepancia en el checksum.

1. Espera a que el propietario del paquete note el problema y vuelva a publicar el paquete para que el checksum sea correcto.


2. Si estás enviando manualmente el módulo único, puedes editar el package-lock.json, encontrar el paquete y reemplazar el checksum ( but got checksum por el wanted checksum) y guardar el archivo package-lock.json y volver a enviar el módulo.

Pero, ¿qué sucede si estás tratando de desplegar inicialmente toda la aplicación y la herramienta de empaquetado sigue ejecutando "npm install" y colocando lo que cree que es el checksum correcto en el archivo package-lock.json antes de llevarlo durante el despliegue (Caso #2)? Podrías descomprimir el archivo mtar, descomprimir el módulo problemático, corregir el archivo package-lock.json, volver a comprimirlo y luego desplegar el archivo mtar, pero qué dolor eso es.

¿Qué pasa si tienes una fecha límite (o simplemente quieres avanzar) y no puedes esperar a que el paquete se corrija en