Preguntas frecuentes sobre la baja de las Extensiones de Firebase

¿Por qué retiraremos Firebase Extensions?

Debido a los próximos cambios y bajas en nuestra infraestructura subyacente de Google Cloud, descontinuaremos el servicio administrado de Firebase Extensions.

¿Las extensiones implementadas existentes dejarán de funcionar después del 31 de marzo de 2027?

No. Las extensiones ya implementadas se ejecutan directamente en la infraestructura estándar de Google Cloud (como Cloud Functions, Eventarc, Cloud Run y Cloud Tasks) y seguirán ejecutándose indefinidamente.

Sin embargo, después del 31 de marzo de 2027, perderás la capacidad de actualizar, volver a configurar o desinstalar estas extensiones a través de la consola o la CLI de Firebase. También perderás la capacidad de descargar tus parámetros de configuración de extensiones existentes para ayudarte a migrar a un kit de funciones. Te recomendamos que migres o exportes la configuración de la extensión antes del 31 de marzo de 2027.

¿Qué sucede si un usuario no hace nada?

Si un usuario no realiza ninguna acción, sus funciones implementadas existentes seguirán ejecutándose como recursos estándar. Sin embargo, después del 31 de marzo de 2027, ocurrirá lo siguiente:

1. No pueden cambiar los parámetros de configuración ni actualizar las variables de entorno.
2. No pueden aplicar correcciones de errores, parches de seguridad ni actualizaciones de dependencias.
3. No pueden descargar la configuración de la extensión para ayudar a configurar de forma idéntica un kit de funciones de reemplazo.
4. Actualmente, la mayoría de las extensiones se compilan en el SDK heredado de Cloud Functions v1, que está vinculado a entornos de ejecución de Node.js más antiguos. Una vez que Google Cloud retire por completo estos tiempos de ejecución heredados, es posible que las funciones dejen de ejecutarse o se inhabiliten. Consulta Compatibilidad con el entorno de ejecución.

¿Hay algo que reemplace a las Extensiones de Firebase?

Agregamos muchas funciones a Cloud Functions para que puedan reemplazar las extensiones. En particular, los kits de funciones, que se pueden distribuir con npm y te permiten implementar varias instancias de funciones, de manera similar a como puedes instalar extensiones varias veces en un solo proyecto.

Sin embargo, cada publicador de extensiones debe determinar si desea publicar un reemplazo oficial del kit de funciones en npm. Dado que las extensiones son de código abierto, si el publicador no quiere hacer un reemplazo oficial, cualquier desarrollador puede bifurcarla para hacer un reemplazo no oficial con Cloud Functions usando nuestras APIs de 2ª gen. en el SDK de Node.

Los publicadores que deseen realizar un reemplazo deben seguir las instrucciones de la guía de migración para publicadores.

Los usuarios que deseen aprovechar los paquetes de reemplazo oficiales o crear sus propios reemplazos pueden seguir las instrucciones de la guía de migración para usuarios.

¿Qué debo hacer como usuario de la extensión?

Si eres usuario de extensiones y ya no usas las que instalaste, desinstálalas antes del 31 de marzo de 2027.

Después de la baja, se quitará el botón "Desinstalar" de la consola de Firebase y los comandos de la CLI correspondientes. Debes borrar de forma manual todos los recursos de Google Cloud asociados, incluidos los secretos individuales de Cloud Functions y Secret Manager, las colas de Cloud Tasks y las cuentas de servicio personalizadas de IAM, con la consola de Google Cloud.

Sin embargo, si usas activamente las extensiones instaladas, te recomendamos que migres a los kits de funciones. Para migrar a los kits de funciones, sigue las instrucciones de nuestra guía de migración para usuarios.

Puedes optar por no migrar a los kits de funciones. En ese caso, te recomendamos que actualices todas tus extensiones a sus versiones más recientes, las mantengas actualizadas y exportes tus configuraciones de extensiones existentes en caso de que desees migrar más adelante.

¿Qué debo hacer como publicador de extensiones?

Te recomendamos que migres tus extensiones publicadas a kits de funciones publicados en npm. Para comenzar, migra tu extensión a las funciones de 2ª gen., lo que es un requisito previo para crear un kit de funciones. Esto implica empaquetar la lógica de tu extensión con el SDK de Cloud Functions v2. Actualizamos el SDK de Cloud Functions v2 para que sea compatible con funciones como la seguridad declarativa y los eventos de ciclo de vida. Ahora puedes migrar el código de extensión existente a una función de 2ª gen. con cambios mínimos en la lógica comercial principal. Estas funciones se pueden publicar con un paquete npm. Para obtener más información, consulta nuestra guía de migración para publicadores.

¿Qué sucede si tengo otras preguntas?

Los usuarios que tengan preguntas pueden consultar nuestra guía de migración para usuarios. Si aún tienes preguntas después de usar la guía, puedes comunicarte con el equipo de Asistencia de Firebase.

Los editores que tengan preguntas sobre cómo migrar Firebase Extensions pueden usar nuestra guía de migración para editores. En esta guía, se incluyen instrucciones para que te mantengas al tanto de las actualizaciones y obtengas ayuda para proporcionar una alternativa a tus extensiones publicadas.

¿Cuáles son las principales rutas de migración disponibles?

A partir de septiembre de 2026, Firebase admitirá oficialmente dos rutas de migración principales:

1. Migra a una función compartida de NPM (“kit de funciones”): Se recomienda para transmitir Firestore a BigQuery y cualquier otro kit de funciones que esté disponible en npm. La lógica principal se empaqueta como una biblioteca NPM estándar con el SDK de Cloud Functions v2. Los usuarios inicializan una base de código Cloud Functions estándar, instalan el paquete, vuelven a exportar las funciones y las implementan de forma independiente con la CLI.
2. Bifurcación y autoadministración: Se recomienda para todas las extensiones que no tengan un kit de funciones disponible en npm. Los usuarios copian o bifurcan el código fuente de la extensión de código abierto, refactorizan los activadores en funciones estándar de Firebase v2 con habilidades de migración de IA de mejor esfuerzo o guías manuales, y asumen la propiedad total de la base de código y su mantenimiento continuo.

¿Qué extensiones se migrarán a kits de funciones?

La extensión Stream Firestore to BigQuery se migró a un kit de funciones disponible como el paquete npm @firebase-function-kits/firestore-bigquery-export.

¿Por qué la migración requiere una actualización de Cloud Functions v1 a v2?

La asistencia estándar de Cloud Functions v1 finaliza con el entorno de ejecución de Node.js 22. Para evitar una "doble migración" en la que los desarrolladores migren de Firebase Extensions solo para verse obligados a realizar una segunda refactorización manual cuando se descontinúen los tiempos de ejecución heredados, Firebase recomienda actualizar de inmediato todas las funciones migradas al SDK de la versión 2 durante esta transición, y esto es obligatorio para los kits de funciones.

Como usuario de Extensions, también puedes crear tus propios kits de funciones con la guía de migración para usuarios.

¿La migración a Cloud Functions autoadministrado cambiará la facturación de un cliente?

Por lo general, no. Las extensiones implementadas ya les cobran a los clientes por los recursos subyacentes de Google Cloud que consumen, como las invocaciones de Cloud Functions, Cloud Storage o el almacenamiento y las consultas de BigQuery. Sin embargo, durante el período de migración, es posible que los clientes incurran en un costo adicional pequeño y temporal si ejecutan la función heredada Firebase Extensions y su función de reemplazo recién implementada en paralelo para garantizar una migración de sistemas segura.

¿Cómo se maneja la facturación de Mandiant o de otras cuentas empresariales especializadas?

Esta baja es un cambio en toda la plataforma que afecta a todos los proyectos de Firebase y Google Cloud. Los acuerdos estándar de facturación y suscripción no se verán afectados. Si los clientes solicitan créditos del ANS debido a un tiempo de inactividad por baja o tienen excepciones de facturación complejas, deriva el caso directamente a través de los canales de asistencia de facturación normales.

¿Cuál es el riesgo de pérdida de datos o tiempo de inactividad del servicio durante la migración?

La transición de recursos administrados a bases de código autoadministradas conlleva un riesgo menor de interrupción del servicio o pérdida de eventos.

• Interrupción del activador: Si se borran los activadores antiguos antes de que se activen los nuevos, se crea una brecha en la que se pierden eventos (p.ej., escrituras de documentos de Cloud Firestore) de forma permanente. Te recomendamos que implementes el kit de reemplazo y lo valides antes de quitar la extensión para evitar la pérdida de datos.
• Brechas de permisos: Si la base de código recién implementada no tiene los permisos de IAM necesarios, las operaciones, como la escritura en BigQuery, fallarán de forma silenciosa o se bloquearán en el tiempo de ejecución. Agregamos seguridad declarativa para las funciones, por lo que la primera implementación del kit que realice una cuenta que pueda consultar y establecer roles, y generar una cuenta de servicio, debería mitigar este problema.

¿Cómo evitamos la pérdida de datos en la extensión de exportación de Cloud Firestore a BigQuery?

Para lograr una transición segura y sin pérdida de datos, el equipo de asistencia debe recomendar a los usuarios que sigan una migración basada en la superposición en lugar de una basada en la brecha. Este es el valor predeterminado con la migración a los kits:

1. Implementa el kit de funciones de reemplazo mientras la extensión aún esté instalada y en ejecución. Espera unos minutos para que Eventarc se aprovisione por completo.
2. Escribe un documento de prueba en la colección Cloud Firestore observada y verifica que la nueva función autoadministrada escriba correctamente una fila correspondiente en la tabla de registro de cambios BigQuery (con un nuevo ID de evento).
3. Una vez que se confirme que la nueva implementación funciona, desinstala o inhabilita de inmediato la extensión heredada para detener el comportamiento de escritura doble.
4. Mantén la ventana de superposición lo más corta posible para minimizar el costo del procesamiento duplicado de cada escritura y la posibilidad de que haya filas duplicadas en el registro de cambios BigQuery sin procesar.
5. En la mayoría de los casos, la tabla de registro de cambios sin procesar (*_raw_changelog) se anulará la duplicación por insertID y, incluso en los casos en los que obtengas filas duplicadas en el registro de cambios, la vista más reciente de la tabla (*_raw_latest) será correcta.

En el README.md del kit, se detalla más información sobre cómo migrar esta extensión en particular y cómo recuperarse de cualquier pérdida de datos.

¿Qué debo hacer si falla el paso de aprovisionamiento del ciclo de vida?

En el servicio administrado, las tareas de configuración (como la creación de conjuntos de datos, tablas y vistas de BigQuery) se manejaban automáticamente. En el modelo de NPM autoadministrado, estas se activan con una función de lista de tareas en cola de ciclo de vida; por ejemplo, en firestore-bigquery-export, se llama initBigQuerySync.

Si este paso falla o no se ejecuta automáticamente, haz lo siguiente:

1. Verifica que se hayan otorgado los roles de IAM necesarios a la cuenta de servicio de tiempo de ejecución de Cloud Functions. Por ejemplo, para firestore-bigquery-export, esto incluye lo siguiente:

   • Para crear recursos e insertar filas, haz lo siguiente: roles/bigquery.dataEditor
   • Para ejecutar trabajos y compilar vistas: roles/bigquery.user
   • Para poner en cola la tarea de aprovisionamiento, haz lo siguiente: roles/cloudtasks.enqueuer

2. Confirma que el llamador tenga permisos de roles/cloudtasks.enqueuer.

3. Vuelve a ejecutar manualmente el comando de inicialización del ciclo de vida con la CLI:

   firebase functions:lifecycle:run afterInstall KIT_INSTANCE_ID
   

4. Revisa los registros de Cloud Logging tanto de la función de activación como de la ejecución de la lista de tareas en cola para diagnosticar cualquier error de permiso o configuración.

¿Cómo se migran las credenciales de Secret Manager?

En el modelo administrado, los recursos de Secret Manager se vinculaban automáticamente a las instancias de extensión. Cuando usas los comandos ext:migrate o ext:export --mode functions para exportar la configuración de tus extensiones a un kit de funciones, impedimos que las extensiones administren estos secretos para que permanezcan en tu proyecto después de que se desinstale la extensión. Si quieres quitar estos secretos en el futuro, debes hacerlo de forma manual en la consola de Google Cloud.

¿Qué sucede si un usuario quiere ejecutar varias instancias de una extensión migrada?

Presentamos los kits de funciones como una forma de admitir varias instancias de una función, de manera similar a cómo podrías tener varias versiones de una extensión. Cada kit obtendrá un ID de instancia de kit único, que es similar a una base de código y se puede usar de forma intercambiable con las bases de código en los comandos de la CLI. Cuando se implementen, todas las funciones de una instancia del kit tendrán el prefijo kit-<instance-id>- para garantizar que cada función tenga un nombre único, de manera similar al prefijo ext-<extension-instance-id>- en las extensiones. Si quieres obtener más información para usar los kits de funciones como parte de la migración, consulta nuestra guía de migración para usuarios.

La instalación de Kit usa npm. ¿Qué sucede si quiero usar Yarn o algún otro administrador de paquetes compatible con Node?

Actualmente, no tenemos planes para admitir Yarn ni otros administradores de paquetes. La instalación del kit funciona ejecutando directamente comandos npm cuando se configura el código fuente del kit en la primera instalación.

Como alternativa, puedes crear un directorio del código fuente, instalar el paquete npm del kit por tu cuenta y configurarlo con las compilaciones y exportaciones adecuadas. Consulta nuestras plantillas de index-kit de TypeScript en firebase-tools o consulta un kit instalado con npm como ejemplo. Una vez que lo hagas, podrás instalarlo como un kit local con --directory en lugar de --package. En el futuro, deberás identificar el kit por directorio o ID, pero puedes usar los comandos del kit para agregar y quitar instancias.

Mi extensión usa los parámetros avanzados del sistema de la clave de KMS o el repositorio de Docker. ¿Cómo puedo configurar esto en los kits de funciones?

Actualmente, no admitimos la configuración de un repositorio de Docker ni de una clave de KMS en Cloud Functions para Firebase. Si migras desde una extensión con estos parámetros del sistema configurados y quieres conservar esta funcionalidad, puedes aplicar los parámetros a las funciones de tu nuevo kit con gcloud CLI.

Requisitos previos

1. Implementa tu kit de funciones inicialmente siguiendo las guías de migración para que las funciones existan en Google Cloud.

2. Define tus variables de entorno en la terminal:

   export PROJECT_ID="YOUR_PROJECT_ID"
   export FUNCTION_REGION="YOUR_REGION"          # e.g. us-east1
   export KIT_NAME="YOUR_KIT_NAME"                # e.g. firestore-bigquery-export
   export SOURCE_DIR="YOUR_KIT_SOURCE_DIR"       # e.g. "./function-kits/${KIT_NAME}/source"
   export REPO_NAME="YOUR_DOCKER_REPO_NAME"
   export KEY_RING="YOUR_KMS_KEY_RING"
   export KEY_NAME="YOUR_KMS_KEY_NAME"
   
   # Retrieve Project Number automatically
   export PROJECT_NUMBER=$(gcloud projects describe "$PROJECT_ID" --format="value(projectNumber)")
   

3. Crea previamente .gcloudignore en la raíz de la fuente del kit para que .gitignore no ignore los archivos de compilación compilados:

   cat << 'EOF' > "${SOURCE_DIR}/.gcloudignore"
   .gcloudignore
   .git
   .gitignore
   
   node_modules
   #!include:.gitignore
   !lib/**
   EOF
   

4. Otorga los permisos de IAM necesarios:

   • Para las claves de KMS (otorga acceso de desencriptación a los agentes de servicio):

     for SERVICE_ACCOUNT in \
       "service-${PROJECT_NUMBER}@serverless-robot-prod.iam.gserviceaccount.com" \
       "service-${PROJECT_NUMBER}@gcf-admin-robot.iam.gserviceaccount.com" \
       "service-${PROJECT_NUMBER}@gcp-sa-artifactregistry.iam.gserviceaccount.com"
     do
       gcloud kms keys add-iam-policy-binding "$KEY_NAME" \
         --keyring="$KEY_RING" \
         --location="$FUNCTION_REGION" \
         --project="$PROJECT_ID" \
         --member="serviceAccount:${SERVICE_ACCOUNT}" \
         --role="roles/cloudkms.cryptoKeyEncrypterDecrypter"
     done
     

   • Para Artifact Registry (otorga acceso de escritura a Cloud Build y acceso de lectura a Cloud Run):

     # Grant the Cloud Build / Compute Service Account permission to write images to the repository
     gcloud artifacts repositories add-iam-policy-binding "$REPO_NAME" \
       --location="$FUNCTION_REGION" \
       --project="$PROJECT_ID" \
       --member="serviceAccount:${PROJECT_NUMBER}-compute@developer.gserviceaccount.com" \
       --role="roles/artifactregistry.writer"
     
     # Grant Cloud Run permission to pull images from the repository
     gcloud artifacts repositories add-iam-policy-binding "$REPO_NAME" \
       --location="$FUNCTION_REGION" \
       --project="$PROJECT_ID" \
       --member="serviceAccount:service-${PROJECT_NUMBER}@serverless-robot-prod.iam.gserviceaccount.com" \
       --role="roles/artifactregistry.reader"
     

Cómo aplicar la configuración con gcloud CLI

Ejecuta gcloud functions deploy para cada función de tu kit:

gcloud functions deploy FUNCTION_NAME \
  --project="$PROJECT_ID" \
  --region="$FUNCTION_REGION" \
  --source="./function-kits/${KIT_NAME}/source" \
  --docker-repository="projects/${PROJECT_ID}/locations/${FUNCTION_REGION}/repositories/${REPO_NAME}" \
  --kms-key="projects/${PROJECT_ID}/locations/${FUNCTION_REGION}/keyRings/${KEY_RING}/cryptoKeys/${KEY_NAME}"

Ten en cuenta que esta solución alternativa no funciona en las siguientes condiciones:

1. Nuevas instancias de kits: Agregar una instancia en firebase.json crea un nuevo recurso Cloud Functions v2 que usa de forma predeterminada claves administradas por Google y gcf-artifacts. Debes ejecutar gcloud para cada instancia nueva.
2. Recreación de la función: Cambiar un tipo de activador (por ejemplo, de HTTPS a un activador de Cloud Firestore), alterar el punto de entrada o cambiar el nombre hace que la CLI de Firebase borre la función anterior y cree una nueva. La nueva función pierde estos parámetros de configuración hasta que vuelvas a ejecutar gcloud.
3. Desviación de la configuración: La CLI de Firebase no muestra el estado del repositorio de KMS o Docker en los registros de firebase functions:list o de diferencias, lo que dificulta la auditoría de la infraestructura.

Verifica si se realizó de forma correcta

Para confirmar que se aplicaron el repositorio y la clave de encriptación, ejecuta el siguiente comando:

gcloud functions describe FUNCTION_NAME \
  --region="$FUNCTION_REGION" \
  --project="$PROJECT_ID" \
  --format="yaml(state, buildConfig.dockerRepository, kmsKeyName)"