Problèmes de mise à jour courants

Lorsqu'une vérification de mise à jour échoue, Capgo renvoie généralement un error code et un message dans la /updates réponse. Cette page explique les échecs les plus courants et les corrections les plus rapides.

Lisez ceci en premier

• no_new_version_available s'est produit un état normal, pas une erreur.
• Beaucoup de rapports « mise à jour trouvée mais non appliquée » sont des refus de politique/ configuration plutôt que des retards de cache, surtout lorsque la réponse inclut une réponse explicite. error code.
• Utilisez npx @capgo/cli@latest app debug tandis que vous reproduisez le problème pour voir les détails de la requête/réponse.

Codes d'erreur courants

provider_infrastructure_request_blocked

La cause est

L'application a Bloque les requêtes d'infrastructure du fournisseur activé et la requête a été initiée à partir d'une plage d'adresses IP de centre de données Google ou Apple connue. Capgo bloque ces requêtes sur /updates, /stats, et /channel_self pour empêcher le trafic provenant du fournisseur d'être traité comme trafic de périphérique.

Fix

• Réproduire l'update à partir d'un appareil physique sur un réseau utilisateur normal.
• N'utilisez pas de sondes hébergées en nuage ou de lanceurs de centre de données du fournisseur pour les mises à jour, les statistiques ou les vérifications de canal-self pendant que cette protection est activée.
• Si ce trafic est intentionnel, ouvrez l'onglet Informations et désactivez Bloque les requêtes d'infrastructure du fournisseur. Réactivez-le lorsque le test est terminé.

Les nouvelles applications ont cette protection activée par défaut. Les applications créées avant que la mise en place du paramètre ne soit introduite gardent cela désactivé jusqu'à ce que vous l'activiez.

Détails de la réponse

• /updates conserve le contrat de réponse de l'actualiseur et renvoie HTTP 200Son corps inclut error, message, kind: "blocked", et provider ("google" ou "apple").
• /stats et /channel_self renvoie HTTP 429 avec le même erreur code. Traitez cela comme une politique de blocage intentionnel, et non comme une condition de réessai transitoire.

disable_auto_update_to_major

Cause

Votre canal bloque les mises à jour majeures (disable_auto_update = majoret la version majeure du bundle cible est supérieure à la version de base du appareil.

Symptôme typique

version: 1.0.8 avec old: 0.0.0 signifie que l'appareil signale la version de base 0.0.0, donc les mises à jour majeures sont rejetées.

Comment l'interpréter

Le serveur compare les versions majeures en utilisant la version de base de l'appareil old et cible version.

• Si cible est 1.0.1, la version majeure de la base doit être 1 (par exemple 1.0.0).
• Si cible est 10.0.1ligne de base majeure doit être 10 (par exemple 10.0.0).

Fixez l'option A (recommandée) : alignez la ligne de base majeure du dispositif

Fixer plugins.CapacitorUpdater.version en capacitor.config.* de sorte que MAJOR correspond à la version MAJOR de votre bundle que vous souhaitez délivrer (par exemple 1.0.0 pour 1.0.1, 10.0.0 pour 10.0.1).

Ensuite, appliquez cette configuration à l'application installée une fois :

1. Exécutez npx cap sync.
2. Reconstruire et réinstaller l'application native.

Fix option B : assouplir la politique de canal

Permettre les mises à jour automatiques inter-majeures dans les paramètres du canal (seulement si cette stratégie de lancement est intentionnelle).

Documents liés :

• Ciblage de version : Désactiver les mises à jour automatiques entre les versions majeures
• Canaux : Désactiver les stratégies de mise à jour automatique

disable_auto_update_to_minor / disable_auto_update_to_patch

Cause

La politique du canal est plus stricte (minor ou patch) que la mise à jour proposée.

• minor empêche lorsque le bundle cible a une version majeure ou mineure différente de la base native du dispositif (version_buildExemple : 1.2.3 -> 1.3.0 est bloqué.
• patch bloque tout changement de numéro majeur, mineur ou de patch, à partir de version_buildSeuls les changements de suffixe sont autorisés tandis que MAJOR.MINOR.PATCH reste identique, comme 1.0.0-beta.1 -> 1.0.0-beta.2 ou 1.0.0+build.1 -> 1.0.0+build.2.

Fixer

• Télécharger un bundle compatible avec la politique actuelle, ou
• changer la politique de canal dans le tableau de bord/CLI.

Documents liés :

• Canaux : Désactiver les stratégies d'actualisation automatique

disable_auto_update_to_metadata

Problème

Le canal utilise une ciblage basé sur les métadonnées (version_number) et le niveau de base du dispositif est inférieur à celui requis min_update_version.

Correction

• Aligner le niveau de base du dispositif (CapacitorUpdater.version) avec la version de l'application native installée, ou
• ajuster min_update_version la stratégie du canal.

Documentation connexe :

• Canaux : Désactiver les stratégies d'actualisation automatique

disable_auto_update_under_native

Problème

Le canal empêche les dégradations en dessous du niveau de base natif.

Réparation

• Téléchargez une version de bundle supérieure ou égale au niveau de base natif, ou
• désactivez la protection de dégradation « sous natif » pour ce canal.

Documents liés :

• Ciblage de version : Prévention de la dégradation automatique

cannot_update_via_private_channel

Cause

Le canal sélectionné/par défaut n'autorise pas l'affectation automatique de l'appareil.

Réparation

• Utilisez un canal différent avec l'affectation automatique activée, ou
• rendez le canal public / activez l'affectation automatique.

Documents liés :

• Canaux : Utilisation de setChannel() à partir de votre application

unknown_version_build / semver_error

Cause

La version de base du dispositif manque (unknown) ou n'est pas valide semver.

Correction

• Fixer plugins.CapacitorUpdater.version à une version semver valide comme 1.2.3.
• Sync and rebuild native app.

Documents connexes :

• Canaux : Gestion de versions et canaux
• Résolution des problèmes : Mises à jour non appliquées

unsupported_plugin_version

Cause

La version du plugin de mise à jour est trop ancienne pour les exigences actuelles du serveur.

Correction

• Mettre à jour @capgo/capacitor-updater.
• Exécuter npx cap sync.
• Rebuilder et réinstaller l'application native.

disabled_platform_ios / disabled_platform_android

Problème

Le canal a désactivé les mises à jour pour cette plateforme.

Correction

• Activer le bouton de la plateforme sur le canal.

disable_prod_build / disable_dev_build / disable_device / disable_emulator

Problème

Le canal interdit le type de build actuel ou le cible de runtime.

Correction

• Aligner les options du canal (allow_prod, allow_dev, allow_device, allow_emulator) avec votre cible de test.

key_id_mismatch

Problème

Les clés d'encryption du bundle et de la clé de l'appareil diffèrent.

Réparer

• Utiliser la même clé d'encryption/clé publique dans la configuration de l'application et le flux de workflow d'encryption du bundle.

no_channel / null_channel_data

Cause

Aucun canal valide n'a été résolu pour l'appareil.

Réparer

• Définir un canal par défaut dans le cloud, ou
• configurer defaultChannel dans les builds de test, ou
• attribuer une surcharge de canal pour appareil.

Documents liés :

• Canaux

on_premise_app

Cause

Le backend a retourné HTTP 429 avec on_premise_app. Cela se produit dans trois situations :

1. L'ID de l'application n'existe pas dans Capgo — le app_id envoyé par le dispositif n'est pas enregistré, donc le backend n'a pas de dossier sur lui.
2. L'application est signalée comme étant sur site — l'application existe mais est configurée pour les mises à jour auto-hébergées, donc le point de terminaison cloud Capgo refuse de le servir.
3. Le plan de l'organisation est annulé — l'application n'a plus d'abonnement actif.

Erreur commune

Une faute d'écriture dans plugins.CapacitorUpdater.appId (en capacitor.config.ts) ou un désaccord avec l'ID de l'application enregistré dans le tableau de bord Capgo. Le serveur ne peut pas distinguer « application inconnue » de « application sur site », il retourne donc le même erreur code.

Réparation

• Vérifiez que app_id correspond exactement à ce qui est affiché dans le tableau de bord Capgo (sensibilité à la casse).
• Si l'application n'est pas encore enregistrée, exécutez npx @capgo/cli@latest app add.
• Si l'application est délibérément sur site, définissez plugins.CapacitorUpdater.updateUrl à votre point de terminaison d'actualisation auto-hébergé au lieu de l'URL cloud Capgo.
• Si le plan d'organisation a expiré, renouvelez ou mettez à niveau le plan.

Liste de vérification rapide de diagnostic

1. Vérifiez que l'ID de l'application et le canal sont corrects pour la build.
2. Confirmer CapacitorUpdater.version correspond à la version native de l'application installée.
3. Confirmer que la politique de canal (disable_auto_update) correspond à la mise en production prévue.
4. Confirmer que les paramètres de plateforme/cible de build autorisent ce dispositif.
5. Exécuter npx @capgo/cli@latest app debug et lire les erreurs de backend code.

Besoin d'aide supplémentaire ?

• Dépannage
• Comment obtenir de l'aide

Continuez de Common Update Problems

Si vous utilisez Common Update Problems pour planifier le travail de plugin natif, connectez-le à En utilisant @capgo/capacitor-mises-à-jour pour la capacité native dans En utilisant @capgo/capacitor-mises-à-jours, Répertoire de plugin Capgo pour le flux de travail du produit dans Répertoire de plugin Capgo, Plugins Capacitor par Capgo pour le détail d'implémentation dans Plugins Capacitor par Capgo Ajouter ou Mettre à Jour les Plugins pour le détail d'implémentation dans Ajouter ou Mettre à Jour les Plugins, et Alternatives de Plugins Entreprise Ionic pour le flux de travail du produit dans Alternatives de Plugins Entreprise Ionic.