assemblee-virtuelle / archipelago

Fostering interconnections between communities by creating synergies between their platforms
Apache License 2.0
14 stars 6 forks source link

[next] Les relations réifiées ne semblent pas fonctionner correctement #142

Closed mguihal closed 8 months ago

mguihal commented 9 months ago

Décrivez le bug Quand j'essaye d'ajouter un membre à une organisation, celui-ci n'est pas persisté après rafraîchissement.

Etapes pour reproduire

  1. Partir d'une installation fraîche d'Archipelago (branche next, base de données vide, dépendances à jour, etc.) [juste pour être sûr que ça ne dépend pas d'un autre facteur]
  2. Se connecter via Archipelago
  3. Créer un rôle dans Concept/Rôles
  4. Créer une organisation
  5. Dans l'onglet "Membres", se rajouter comme membre, avec le rôle nouvellement créé
  6. Sauvegarder
  7. Constater que lorsqu'on revient sur la page d'édition de l'organisation / onglet Membres, il n'y a plus aucune relation

Dans les logs du middleware, on constate l'erreur suivante :

TypeError: fetch failed
    at Object.fetch (node:internal/deps/undici/undici:11413:11)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async FetchAdapter.resolveById (/Users/maxime/Documents/workspaces/transiscope/archipelago/middleware/node_modules/ldp-navigator/src/adapter/FetchAdapter.js:17:26)
    at async LDPNavigator.resolveById (/Users/maxime/Documents/workspaces/transiscope/archipelago/middleware/node_modules/ldp-navigator/src/LDPNavigator.js:253:29)
    at async LDPNavigator.get (/Users/maxime/Documents/workspaces/transiscope/archipelago/middleware/node_modules/ldp-navigator/src/LDPNavigator.js:382:31)
    at async LDPNavigator.dereference (/Users/maxime/Documents/workspaces/transiscope/archipelago/middleware/node_modules/ldp-navigator/src/LDPNavigator.js:437:27)
    at async Service.handleAfterGet (/Users/maxime/Documents/workspaces/transiscope/archipelago/middleware/mixins/dereference.js:34:19)
    at async Service.get (/Users/maxime/Documents/workspaces/transiscope/archipelago/middleware/node_modules/@semapps/ldp/services/api/actions/get.js:65:24)
    at async Service.callAction (/Users/maxime/Documents/workspaces/transiscope/archipelago/middleware/node_modules/moleculer-web/src/index.js:644:16)
    at async /Users/maxime/Documents/workspaces/transiscope/archipelago/middleware/node_modules/moleculer-web/src/index.js:469:22 {
  cause: Error: connect ECONNREFUSED ::1:3000
      at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1494:16) {
    errno: -61,
    code: 'ECONNREFUSED',
    syscall: 'connect',
    address: '::1',
    port: 3000
  }
}

Suis-je le seul à reproduire ? cc @BastienSig

srosset81 commented 9 months ago

Problème avec LDPNavigator visiblement qui a été ajouté en surcouche à l'action ldp.resource.get. Ping @simonLouvet

BastienSig commented 8 months ago

Je regarde ça ce matin

mguihal commented 8 months ago

Je ne comprends pas, même après la correction que tu as mergé, j'ai toujours le souci :/ Je suis un peu coincé sur ce sujet... je pense que je vais être obligé de mettre les mains dedans pour comprendre ce que fait le LDPNavigator exactement 😬

srosset81 commented 8 months ago

@mguihal Pour info l'usage de LdpNavigator est un hack donc ne te prend pas trop la tête. Comme on est au niveau middleware, on pourrait simplement appeler l'action ldp.resource.get sans passer par LdpNavigator. Mais la vraie solution serait de réécrire proprement les composants utilisés pour les relations réifiées. Voir cette issue notamment: https://github.com/assemblee-virtuelle/semapps/issues/894

mguihal commented 8 months ago

Après investigations, j'ai trouvé le pourquoi du comment. Il se trouve que LdpNavigator utilise l'api fetch de Node, qui a du mal avec les requêtes sur les serveurs locaux selon leurs paramètres visiblement (merci à cette réponse qui m'a aiguillé sur StackOverflow https://stackoverflow.com/questions/74165121/next-js-fetch-request-gives-error-typeerror-fetch-failed)

Il se trouve que par défaut, l'adresse locale du middleware est configurée comme http://localhost:3000/, mais que moleculer-web utilisé dedans lance son serveur par défaut sur l'ip 0.0.0.0, d'où l'erreur. Cette ip est personnalisable soit via les settings de moleculer-web, soit via la variable d'environnement IP (https://github.com/moleculerjs/moleculer-web/blob/master/src/index.js#L61).

En ajoutant cette variable IP=localhost dans le fichier .env du middleware, ça marche nickel 👌 C'est bon à savoir ^^

srosset81 commented 8 months ago

Merci pour l'info ! Cela donne une raison de plus d'utiliser des actions type ldp.resource.get plutôt que LdpNavigator lorsqu'on est sur le middleware. @simonLouvet Faire un fetch sur son propre serveur comporte des risques, j'en ai aussi fait l'expérience avec certaines config Docker.

simonLouvet commented 7 months ago

son propre serveur comport

L'intérêt d'utiliser LdpNavigator plutôt que ldp.resource.get c'est de pouvoir paramétrer simplement un plan de déréférencement qui peut être complexe. C'est configurable par un object json. Avec ldp.resource.get il faudra faire du code spécifique sur mesure pour chaque container custom. Je suis d'accord que la solution cible est de déréférencer et desasembly sur navigateur. @mguihal je n'ai pas vraiment compris comment molecurer peut choisir son ip car pour moi c'est de la responsabilité de docker mais je suis curieux de comprendre et pourquoi ça n'arrive pas sur nos (moi et bastien) machines et le serveur. peut être windows?