Recharger ou redémarrer

Se tromper ici coûte soit un redémarrage de 4D inutile, soit, pire, une heure passée à déboguer un code qui n'a jamais été chargé. Cette page dit quoi faire selon ce que vous avez modifié, et comment savoir que cela a marché.

La décision

Mesures faites sur une base de test, sous 4D 21.1, avec l'environnement Design ouvert, et consignées dans le source du composant lui-même (ClaudeAPI.4dm, reloadProject) :

host method changed ........ reloaded (< 4 s)
host class changed ......... reloaded (< 4 s)
host method created hot .... loaded (not found before, callable after)
COMPONENT method ........... NOT reloaded (still v1 after 24 s)
COMPONENT class ............ NOT reloaded

Autrement dit : une méthode ou une classe de l'hôte, modifiée, est rechargée en moins de 4 secondes ; une méthode de l'hôte créée à chaud devient appelable ; une méthode ou une classe du composant n'est pas rechargée.

Le serveur web reste disponible pendant un rechargement : toutes les requêtes reçoivent une réponse.

Pour une NOUVELLE fonction, l'ordre est imposé

Rechargement puis BSPK_REFRESH_STORAGE. Jamais le rafraîchissement seul.

BSPK_REFRESH_STORAGE analyse la classe telle qu'elle est actuellement en mémoire. Lancé seul après l'ajout d'une fonction, il réécrit consciencieusement les listes JSON — ce qui donne l'impression que cela a marché — mais sans la nouvelle fonction. Vérifié : le rafraîchissement seul laisse l'appel muet ; rechargement puis rafraîchissement le rend appelable aussitôt.

Ce que fait réellement le rafraîchissement :

• il recharge toutes les traductions ;
• il réanalyse les méthodes et classes appelables dans Storage.vo_AvailableController(ForSelect), la liste blanche du dispatch ;
• il recharge les gabarits HTML ;
• il recopie les dépendances bweb.

En mode compilé, il relit des JSON générés à l'avance au lieu d'analyser les classes : c'est pourquoi ces fichiers doivent être livrés avec le build.

À savoir : Resources/json/AvailableController est dans un format binaire 4D (octets magiques \x01\x02). Y chercher un texte ne prouve rien ; regardez plutôt sa date de modification.

Deux façons dont RELOAD PROJECT ne fait rien, en silence

1. La commande est asynchrone. Un appel qui répond « succès » signifie que la commande a été lancée, pas que le code est actif.
2. Sans environnement Design ouvert (application fusionnée), elle ne fait rien du tout, et 4D n'offre aucun moyen de le détecter.

Ne concluez donc jamais sur le temps écoulé, ni sur le succès de l'appel HTTP. Concluez sur une trace que seul le nouveau code peut produire : une ligne de journal, une valeur modifiée, un nouveau champ dans une réponse. Sans une telle trace, vous ne savez pas si votre code est chargé.

Exception connue : la création d'un nouveau .4dm dans l'hôte s'est montrée non déterministe — une méthode est restée invisible environ cinq minutes malgré trois rechargements, puis est apparue. Si la preuve échoue après un rechargement, redémarrez plutôt que d'insister.

Redémarrer proprement

Redémarrez par la commande RESTART 4D (la méthode hôte restart4D, appelable par /_claude/exec). Jamais par taskkill /F : un arrêt forcé ne libère pas le port web tout de suite, et le démarrage suivant échoue avec l'erreur [10048].

Un redémarrage ne suffit pas toujours non plus à lui seul : le code du composant a déjà eu besoin, à deux reprises, d'un second appel avant de servir réellement la nouvelle version. Même règle : prouvez-le.

Conseil : les routes /_claude sont des outils de développement. Ne les exposez pas sur Internet.

Après un redémarrage, la session du navigateur est perdue

La session web de développement est perdue, et le dev-panel disparaît. Reconnectez-vous par POST /bweb/login, puis rechargez la page.

Voir aussi

• L'API Claude — les routes reload et exec
• Le cycle d'une requête — pourquoi une variable process périmée peut ressembler à du code périmé