Mongoose: No se realizan reintentos después de "no se pudo conectar en la primera conexión"

puede confirmar.
nodo 6, 7, mangosta (al menos 6 meses), mongo 3.2 - 3.4
viene junto con este # 4890

Supongo que esto es un problema de mongodb-core . Debería intentar volver a conectarse incluso si el primer intento falla, creo, ya que no estoy seguro de por qué eso sería diferente de los intentos posteriores.

¿También puede informar de este problema allí?

Aquí hay un guión de reproducción completo:

const mongoose = require('mongoose');
const co = require('co');
mongoose.Promise = global.Promise;
const GITHUB_ISSUE = `gh-5169`;


exec()
  .catch(error => {
    console.error(`Error: ${ error }\n${ error.stack }`);
  });


function exec() {
  return co(function*() {
    const db = mongoose.createConnection(`mongodb://localhost:27017/${ GITHUB_ISSUE }`);
    db.on('error', (error) => {
      console.error(`in an error ${ error }\n${ error.stack }`);
    })
  });
}

Gracias por la repro. He mirado en mongodb-core. Es el comportamiento previsto del conductor :

El controlador fallará en la primera conexión si no puede conectarse al host. Esto es por diseño para garantizar un fallo rápido en hosts inalcanzables. El comportamiento de reconexión solo se activa una vez que el controlador ha realizado la conexión inicial.

Depende de la aplicación decidir qué hacer. Esto es por diseño para garantizar que el controlador falle rápidamente y no se quede ahí, haciéndole pensar que realmente está funcionando.

Así que sospecho que no obtendremos ningún comportamiento diferente del conductor.

De hecho, creo que el comportamiento es razonable para un conductor de bajo nivel. Ayudará a los desarrolladores que accidentalmente intenten conectarse al host incorrecto o al puerto incorrecto.

Pero si queremos hacer algo más amigable para los desarrolladores en mangosta, podríamos considerar:

• Cuando las opciones de reconexión automática estén habilitadas, siga intentando reconectarse hasta que se pueda contactar con el servidor Mongo (incorporando algo como la solución alternativa vinculada anteriormente).
• Inicie sesión cuando mangosta esté haciendo esto, por lo que en el caso de una conexión que nunca se establece, el desarrollador al menos sabrá dónde está el problema.
  (El registro podría posponerse, por ejemplo, 30 segundos. En realidad, en lugar del registro directo, supongo que deberíamos emitir un evento de aviso error , pero aún así intentar la reconexión automáticamente).

Si mal no recuerdo, cuando utilicé la solución alternativa y finalmente me conecté después de algunos intentos fallidos, las consultas que la aplicación ya había puesto en cola se ejecutaron como deseaba. (Pero vale la pena probarlo de nuevo).

Creo que esta es una idea decente en realidad, la etiquetaré como una solicitud de función.

No, fallar rápidamente en la conexión inicial es un comportamiento bastante consistente en los controladores MongoDB y no hay mucho beneficio en que la mangosta lo admita.

Esta publicación reciente del conector mongodb Strongloop Loopback puede ser relevante. Su bandera lazyConnect pospone la primera conexión hasta que se alcanza el punto final. Si la primera conexión falla en ese caso, la configuración de pérdida de conexión predeterminada entrará en vigencia (volverá a intentarlo).

Mi interés es la orquestación de contenedores, donde el "orden de inicio del contenedor" a menudo se puede establecer y esperar, pero el "orden de disponibilidad del servicio" no. Una herramienta de orquestación podría confirmar que el contenedor de mongo está "activo" aunque el servicio de mongo aún no esté disponible.

Por lo tanto, si mi contenedor mongo tarda 1 s en iniciarse, pero 5 s en que el servicio esté disponible, y el contenedor de mi aplicación tarda 1 s en iniciarse y 1 s en que el servicio esté disponible, el servicio de la aplicación superará al servicio mongo, lo que provocará una primera falla de conexión. como se describió originalmente .

La documentación de Docker Compose tiene esto que decir:

Compose no esperará hasta que un contenedor esté "listo" (sea lo que sea que eso signifique para su aplicación en particular), solo hasta que se esté ejecutando. Hay una buena razón para esto.

El problema de esperar a que una base de datos (por ejemplo) esté lista es en realidad solo un subconjunto de un problema mucho mayor de los sistemas distribuidos. En producción, su base de datos podría dejar de estar disponible o mover hosts en cualquier momento. Su aplicación debe ser resistente a este tipo de fallas.

Para manejar esto, su aplicación debe intentar restablecer una conexión a la base de datos después de una falla. Si la aplicación reintenta la conexión, eventualmente debería poder conectarse a la base de datos.

La mejor solución es realizar esta verificación en el código de su aplicación, tanto al inicio como siempre que se pierda una conexión por cualquier motivo .

Entonces, hay una brecha definida aquí en el contexto de la orquestación de contenedores, pero ambas posturas parecen ser válidas:

1. Mongoose podría admitir una opción para reintentar en la primera conexión (quizás predeterminada en falso con alguna documentación de advertencia), o
2. Mongoose podría responsabilizar al desarrollador de escribir código para reintentarlo si falla la primera conexión.

Claro, hay una brecha, pero luego la responsabilidad recae en usted para decidir si volver a intentarlo si falla la conexión inicial. Todo lo que la mangosta te dice es que falló. Si toma la decisión cuestionable de usar Docker Comose en producción (o en cualquier contexto), depende de usted manejar los reintentos de fallas de conexión iniciales.

Postura 2, entonces.

Para cualquiera que desee una reconexión automática cuando falla la primera conexión, así es como lo manejo:

function createConnection (dbURL, options) {
    var db = mongoose.createConnection(dbURL, options);

    db.on('error', function (err) {
        // If first connect fails because mongod is down, try again later.
        // This is only needed for first connect, not for runtime reconnects.
        // See: https://github.com/Automattic/mongoose/issues/5169
        if (err.message && err.message.match(/failed to connect to server .* on first connect/)) {
            console.log(new Date(), String(err));

            // Wait for a bit, then try to connect again
            setTimeout(function () {
                console.log("Retrying first connect...");
                db.openUri(dbURL).catch(() => {});
                // Why the empty catch?
                // Well, errors thrown by db.open() will also be passed to .on('error'),
                // so we can handle them there, no need to log anything in the catch here.
                // But we still need this empty catch to avoid unhandled rejections.
            }, 20 * 1000);
        } else {
            // Some other error occurred.  Log it.
            console.error(new Date(), String(err));
        }
    });

    db.once('open', function () {
        console.log("Connection to db established.");
    });

    return db;
}

// Use it like
var db = createConnection('mongodb://...', options);
var User = db.model('User', userSchema);

Para mangosta <4.11 use db.open() lugar de db.openUri()
Para mangosta 4.11.7 esta técnica no funciona.
¡Para mangosta 4.13.4 está funcionando de nuevo!

Editar 02/09/2019: También hay una solución más corta usando promiseRetry aquí .

Hola @ vkarpov15, cuando esto ocurra, también registre un Rechazo no controlado de la biblioteca mongodb-core.

MongoError: failed to connect to server [localhost:27017] on first connect [MongoError: connect ECONNREFUSED 127.0.0.1:27017]
    at Pool.<anonymous> (/Users/development/okkralabs/sem-server/services/sem-access/node_modules/mongodb-core/lib/topologies/server.js:336:35)
    at emitOne (events.js:116:13)
    at Pool.emit (events.js:211:7)
    at Connection.<anonymous> (/Users/development/okkralabs/sem-server/services/sem-access/node_modules/mongodb-core/lib/connection/pool.js:280:12)
    at Object.onceWrapper (events.js:317:30)
    at emitTwo (events.js:126:13)
    at Connection.emit (events.js:214:7)
    at Socket.<anonymous> (/Users/development/okkralabs/sem-server/services/sem-access/node_modules/mongodb-core/lib/connection/connection.js:187:49)
    at Object.onceWrapper (events.js:315:30)
    at emitOne (events.js:116:13)
    at Socket.emit (events.js:211:7)
    at emitErrorNT (internal/streams/destroy.js:64:8)
    at _combinedTickCallback (internal/process/next_tick.js:138:11)
    at process._tickCallback (internal/process/next_tick.js:180:9)

Esto es fácil de reproducir, intente conectarse con un servidor MongoDb no disponible.

(node:2545) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): MongoError: failed to connect to server [localhost:27017] on first connect [MongoError: connect ECONNREFUSED 127.0.0.1:27017]
(node:2545) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

¿Alguna forma de manejarlo?

@jorgearanda ¿qué versión de mangosta estás usando y puedes proporcionar algunos ejemplos de código?

@ vkarpov15 Creo que es un mensaje para @jorgecuesta .

Woops, mi error. Silly github autocomplete, sí, eso fue para @jorgecuesta

Veo exactamente lo mismo que @jorgecuesta , estaba usando 4.11.5 y veo lo mismo con 5.0.0-rc2. Estoy usando createConnection ya que algunos de los modelos usan diferentes bases de datos en la misma instancia de mongo. Ocurre al iniciar el servidor mientras mongo está inactivo:

2018-01-07 13:05:23-05:00: [INFO] database - reusing existing connectioun for mongodb://localhost/eiss
2018-01-07 13:05:23-05:00: [INFO] database - initializing database connection to: mongodb://localhost/eiss
2018-01-07 13:05:23-05:00: [INFO] database - reusing existing connectioun for mongodb://localhost/eiss
2018-01-07 13:05:23-05:00: [ERROR] database - Mongoose connection error: MongoNetworkError: failed to connect to server [localhost:27017] on first connect [MongoNetworkError: connect ECONNREFUSED 127.0.0.1:27017]
Unhandled rejection MongoNetworkError: failed to connect to server [localhost:27017] on first connect [MongoNetworkError: connect ECONNREFUSED 127.0.0.1:27017]
    at Pool.<anonymous> (/Users/bill/eiss4/js/node_modules/mongoose/node_modules/mongodb-core/lib/topologies/server.js:503:11)
    at emitOne (events.js:116:13)
    at Pool.emit (events.js:211:7)
    at Connection.<anonymous> (/Users/bill/eiss4/js/node_modules/mongoose/node_modules/mongodb-core/lib/connection/pool.js:326:12)
    at Object.onceWrapper (events.js:317:30)
    at emitTwo (events.js:126:13)
    at Connection.emit (events.js:214:7)
    at Socket.<anonymous> (/Users/bill/eiss4/js/node_modules/mongoose/node_modules/mongodb-core/lib/connection/connection.js:245:50)
    at Object.onceWrapper (events.js:315:30)
    at emitOne (events.js:116:13)
    at Socket.emit (events.js:211:7)
    at emitErrorNT (internal/streams/destroy.js:64:8)
    at _combinedTickCallback (internal/process/next_tick.js:138:11)
    at process._tickCallback (internal/process/next_tick.js:180:9)

Los modelos llaman a una función de conexión con el nombre de la base de datos que están usando (abajo). Siempre que mongo se esté ejecutando cuando se inicia el servidor, subir y bajar la base de datos se vuelve a conectar bien (registrando los errores). Al leer este número, me di cuenta de que el controlador maneja la conexión inicial de manera diferente, lo cual es un poco molesto. Voy a probar la solución alternativa de @joeytwiddle , pero sospecho que esta excepción no controlada seguirá ocurriendo.

const allConnections = {};

module.exports = function(dbName) {
  const url = 'http://localhost/' + dbName;
  let conn;
  log.info('initializing database connection to: ' + url);

  conn = allConnections[url];
  if (!conn) {
    log.info('creating new connection for ' + url);
    conn = mongoose.createConnection(url, {
      useMongoClient: true,
      autoReconnect: true,
      autoIndex: false,
      reconnectTries: Number.MAX_SAFE_INTEGER
    });    
    // Log database connection events
    conn.on('connected', () => log.info('Mongoose connection open to ' + url));
    conn.on('error', (err) =>  log.error('Mongoose connection error: ' + err));
    conn.on('disconnected', () => log.error('Mongoose connection disconnected'));  
    allConnections[url] = conn;
  }
  else {
    log.info('reusing existing connection for ' + url);
  }
  return conn;
}

@raythree en el caso anterior debería estar bien porque tiene .on('error') . Si desea volver a intentar la conexión inicial si falla, le recomiendo que use async / await para eso.

let conn;
for (let i = 0; i < numRetries; ++i) {
  try {
    conn = await mongoose.createConnection(uri);
    break;
  } catch (error) {}
}

@ vkarpov15 Perdón por la demora en responderte, estamos usando 4.11.14 y 4.13.4

@jorgecuesta do mongoose.connect(uri).catch(err => {})

@ vkarpov15 connect () devuelve la instancia de conexión, ¿verdad?

const connection = mongoose.connect(uri || undefined, {useMongoClient: true});
connection.once('error', (e) => {
  console.error(e, 'mongoose connection error.');
});
connection.once('connected', () => {
  console.log('mongoose connected');
});

En 5.0.0 lo cambiamos para que mongoose.connect() devuelva una promesa de manera consistente. En 4.x devuelve una instancia de conexión pero con .then() y .catch() para que pueda usarlo con await

Hola @joeytwiddle.

Tengo el mismo problema en la implementación de Heroku.
MongoNetworkError: failed to connect to server [localhost:27017] on first connect [MongoNetworkError: connect ECONNREFUSED 127.0.0.1:27017]

En su comentario del 12 de julio de 2017, dio una solución temporal. Soy nuevo en Mongoose / Node. ¿Puede decirme en qué archivo debe ir su función createConnection?

Estoy ejecutando mangosta: ^ 5.0.10, nodo: v9.4.0
Salud

@juancarlucci Puedes ponerlo en el archivo que quieras. Simplemente llámelo para obtener una instancia de mangosta y úselo para crear sus modelos.

He actualizado el comentario anterior para mostrar un ejemplo de uso.

@joeytwiddle ¡ Gracias por el ejemplo de uso! Salud.

Cuando intento conectarme a mongo, arroja un error:

connection error: { MongoNetworkError: failed to connect to server [localhost:27017] on first connect [MongoNetworkError: connection 0 to localhost:27017 timed out]
    at Pool.<anonymous> (/home/wasd_xyz/Desktop/test/node_modules/mongodb-core/lib/topologies/server.js:505:11)
    at emitOne (events.js:116:13)
    at Pool.emit (events.js:211:7)
    at Connection.<anonymous> (/home/wasd_xyz/Desktop/test/node_modules/mongodb-core/lib/connection/pool.js:329:12)
    at Object.onceWrapper (events.js:317:30)
    at emitTwo (events.js:126:13)
    at Connection.emit (events.js:214:7)
    at Socket.<anonymous> (/home/wasd_xyz/Desktop/test/node_modules/mongodb-core/lib/connection/connection.js:256:10)
    at Object.onceWrapper (events.js:313:30)
    at emitNone (events.js:106:13)
    at Socket.emit (events.js:208:7)
    at Socket._onTimeout (net.js:420:8)
    at ontimeout (timers.js:482:11)
    at tryOnTimeout (timers.js:317:5)
    at Timer.listOnTimeout (timers.js:277:5)
  name: 'MongoNetworkError',
  message: 'failed to connect to server [localhost:27017] on first connect [MongoNetworkError: connection 0 to localhost:27017 timed out]' }
(node:5453) UnhandledPromiseRejectionWarning: MongoNetworkError: failed to connect to server [localhost:27017] on first connect [MongoNetworkError: connection 0 to localhost:27017 timed out]
    at Pool.<anonymous> (/home/wasd_xyz/Desktop/test/node_modules/mongodb-core/lib/topologies/server.js:505:11)
    at emitOne (events.js:116:13)
    at Pool.emit (events.js:211:7)
    at Connection.<anonymous> (/home/wasd_xyz/Desktop/test/node_modules/mongodb-core/lib/connection/pool.js:329:12)
    at Object.onceWrapper (events.js:317:30)
    at emitTwo (events.js:126:13)
    at Connection.emit (events.js:214:7)
    at Socket.<anonymous> (/home/wasd_xyz/Desktop/test/node_modules/mongodb-core/lib/connection/connection.js:256:10)
    at Object.onceWrapper (events.js:313:30)
    at emitNone (events.js:106:13)
    at Socket.emit (events.js:208:7)
    at Socket._onTimeout (net.js:420:8)
    at ontimeout (timers.js:482:11)
    at tryOnTimeout (timers.js:317:5)
    at Timer.listOnTimeout (timers.js:277:5)
(node:5453) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:5453) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

estado de mongodb del servicio sudo

● mongodb.service - MongoDB Database
   Loaded: loaded (/etc/systemd/system/mongodb.service; enabled; vendor preset: 
   Active: active (running) since Sat 2018-06-23 17:13:28 IST; 13min ago
     Docs: https://docs.mongodb.org/manual
 Main PID: 4224 (mongod)
    Tasks: 24 (limit: 4915)
   CGroup: /system.slice/mongodb.service
           └─4224 /usr/bin/mongod --quiet --config /etc/mongod.conf

Jun 23 17:13:28 Inspiron5370 systemd[1]: Started MongoDB Database.

@pranshuchittora ¿puedes mostrar tu archivo de configuración de MongoDB? Asegúrese de que el puerto sea 27017. Además, intente usar 127.0.0.1 en lugar de localhost

Intente conectarse con ip en lugar de localhost que solucionará su problema.

 let local = "mongodb://127.0.0.1:27017/XXX";
      mongoose.connect(
        local,
        { useNewUrlParser: true }
      );

Si el primer intento de conexión falla, siempre arroja un error.
Puede omitir esto usando a continuación (por ejemplo, cuando desee asegurarse de que la base de datos se esté ejecutando antes de que se inicie la aplicación / script):

[email protected]
@ tipos / [email protected]
@ tipos / [email protected]

async function waitForMongoDBStart(uri: string, timeoutMs: number) {

    return new Promise( async (resolve, reject) => {

        let endTime = Date.now() + timeoutMs;


        while (true) {

            let connectionError: Error;

            function errorHandler(err: Error) {
                connectionError = err;
            }
            mongoose.connection.once("error", errorHandler);

            await mongoose.connect(uri, {
                connectTimeoutMS: 5000, // This timeout applies only after connected & connection lost
                useNewUrlParser: true,
                useFindAndModify: false
            });

            // Time for error event propagation
            await wait(0);

            if ( ! connectionError) {
                mongoose.connection.removeListener("error", errorHandler);
                return resolve(); // All OK, connected
            }

            if (connectionError.name !== "MongoNetworkError") {
                return reject(`Unable to connect mongoDB. Details: ${connectionError}`);
            }

            if (Date.now() > endTime) {
                return reject(`Unable to connect mongoBD in ${timeoutMs} ms. Details: ${connectionError}`);
            }

        }

    });
}

@ vkarpov15 Este es un comportamiento muy poco obvio. De https://mongoosejs.com/docs/connections.html :

connectTimeoutMS - How long the MongoDB driver will wait 
before failing its initial connection attempt. 
Once Mongoose has successfully connected, connectTimeoutMS is no longer relevant.

La documentación dice que debería funcionar con la conexión inicial, pero no es así. Con el error failed to connect to server , falla inmediatamente.

Si es un comportamiento consistente en los controladores MongoDB, sería bueno tener alguna opción como reconnectOnInitialFail que será false por defecto

El comportamiento actual es opuesto al descrito por vkarpov15 -
connectImeoutMS solo importa después de la primera conexión (en la primera conexión
Se espera que DB se inicie y acepte la conexión; de lo contrario, inmediatamente
se lanza error)

sollozo., 22 de gru 2018 o 13:03 Dmitry Kirilyuk [email protected]
napisał (a):

Si es un comportamiento consistente en los controladores MongoDB, sería bueno
tener alguna opción como reconnectOnInitialFail que será falsa por
defecto

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/Automattic/mongoose/issues/5169#issuecomment-449565468 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ABY-TjgeI2UqVca050y5YY3zi6w7nMkfks5u7h-vgaJpZM4M-1ur
.

-
Wojciech Fiderek

Móvil: +48516661428

Si mal no recuerdo, connectTimeoutMS importa en la conexión inicial dependiendo de las condiciones de la red y del sistema operativo. ¿Cuándo importa connectTimeoutMS después de la conexión inicial?

En mi caso, se produjo un error inmediato cuando no pude conectarme en el primer intento a la instancia localhost mongod en Windows 10 y Alpine Linux (versión desconocida). La instancia de Mongod aún no ha comenzado.
¿Otros ejemplos además de localhost? ¿Alguien?

@fider @Jokero Investigué más, y tengo razón, connectTimeoutMS solo importa hasta que haya realizado una conexión inicial, socketTimeoutMS hace cargo después. Aquí está el código relevante en el controlador MongoDB:

• https://github.com/mongodb-js/mongodb-core/blob/177e558be28e5505ce1eb4a94b35d05130d34e76/lib/connection/connection.js#L599
• https://github.com/mongodb-js/mongodb-core/blob/177e558be28e5505ce1eb4a94b35d05130d34e76/lib/connection/connection.js#L604

connectTimeoutMS no siempre es útil porque normalmente obtendrá un error de DNS o un error de conexión rechazada. Pero si, por ejemplo, abre un servidor TCP que escucha en un puerto pero en realidad no hace nada:

const net = require('net');

const server = net.createServer();

server.listen(27055);

Verás que connectTimeoutMS entra en acción:

const assert = require('assert');
const mongoose = require('mongoose');
mongoose.set('debug', true);

const { Schema } = mongoose;

run().then(() => console.log('done')).catch(error => console.error(error.stack));

async function run() {
  await mongoose.connect('mongodb://localhost:27055', {
    useNewUrlParser: true,
    connectTimeoutMS: 1000,
    socketTimeoutMS: 25000
  });
} 

$ time node gh-5169.js 
MongoNetworkError: connection 0 to localhost:27055 timed out
    at Socket.<anonymous> (/mongoose/node_modules/mongodb-core/lib/connection/connection.js:259:7)
    at Object.onceWrapper (events.js:313:30)
    at emitNone (events.js:106:13)
    at Socket.emit (events.js:208:7)
    at Socket._onTimeout (net.js:407:8)
    at ontimeout (timers.js:475:11)
    at tryOnTimeout (timers.js:310:5)
    at Timer.listOnTimeout (timers.js:270:5)

real    0m2.293s
user    0m0.271s
sys 0m0.043s
$ 

a veces debido a restricciones de red, la URL de MongoDB se bloquea, intente cambiar su fuente de red / Internet.

https://stackoverflow.com/questions/47958683/cannot-connect-to-mongodb-atlas-through-mongo-shell?answertab=active#tab -top

Al hacer una conexión inicial, (al menos) pueden suceder tres cosas:

1. Hay un mongodb y la conexión se realiza correctamente, ¡yay!

2. El servidor responde "Conexión rechazada", lo que significa que no hay ningún proceso escuchando en este puerto, o hay un firewall que _ rechazó activamente_ la conexión. (Esto suele suceder de inmediato, y creo que esto es lo que estaba experimentando Fider).

3. El servidor no responde en absoluto, por ejemplo, el cortafuegos _ descartó pasivamente_ los paquetes o no hay ningún servidor en esa dirección IP. (En este caso, connectTimeoutMS vkarpov finalmente se activa).

Por tanto, el tiempo de espera no siempre se utiliza. Solo se usa si no hay un éxito o fracaso claro en el tiempo dado.

Esto es común en las redes y también cuando se habla con una persona que no coopera. Su solicitud puede tener dos tipos de rechazo: "¡NO!" y .....

Gracias por la sólida explicación @joeytwiddle : +1:

¿Cómo se debe manejar este comportamiento con conexiones de conjuntos de réplicas usando mongodb+srv ? Cuando mi conjunto de réplicas se encuentra en un escenario de reinicio continuo (actualización de la base de datos), empiezo a recibir errores como connect ECONNREFUSED 34.238.xxx.xxx:27017 .

@esetnik, ¿estás usando useUnifiedTopology: true y Mongoose 5.7.5? Identificamos un problema n. ° 8209 que podría estar relacionado.

@ vkarpov15 ¡ sí, lo soy! Gracias por el consejo. Ejecutaré algunas pruebas después de deshabilitar la topología unificada e informaré mis hallazgos.

Hola. Tengo exactamente el mismo problema en mi proyecto. ¿Has encontrado alguna solución para ello?

@fdmxfarhan , abra un problema por separado y siga la plantilla de problemas.