blomios/IdeA
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
8fe93d165208e664ef7ab557d87c979308fccf6b
IdeA/.ideai/tickets/74/issue.md
Blomios 481a7e2498 chore(ideai): clôture de #74 et #68, ouverture de #75 et #76 
Enregistre l'état du registre de tickets : #74 et #68 passent en closed
après la validation live de l'intégration web, #75 (ce fix) entre en QA
et #76 ouvre la dette de casse du code d'appairage côté serveur.

État runtime uniquement : aucun code de feature n'est touché.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-17 10:40:26 +02:00

3.4 KiB
Raw Blame History

id, number, title, status, priority, sprint, links, agentRefs, createdBy, updatedBy, createdAt, updatedAt, version
id number title status priority sprint links agentRefs createdBy updatedBy createdAt updatedAt version
249bb0de-118f-4d6f-b0c4-1d4e2aadd83f 74 Le serveur embarqué sert le bundle desktop (Tauri) au navigateur — __TAURI_INTERNALS__ undefined closed high null
target kind
#68 relatesTo
target kind
#66 relatesTo
target kind
#13 relatesTo
kind agent_id
agent a6ced819-b893-4213-b003-9e9dc79b9641
kind agent_id
agent a6ced819-b893-4213-b003-9e9dc79b9641
1784271086298 1784277308704 3

Symptôme (constaté live, exposition derrière reverse proxy)

UI chargée dans le navigateur via https://idea.anthonybouteiller.ovh (nginx → 192.168.1.75:17373, serveur embarqué desktop, mode remoteProxyOtherMachine) :

  • Error: can't access property "invoke", window.__TAURI_INTERNALS__ is undefined (x2)
  • Aucun projet affiché.

Cause racine (confirmée)

crates/app-tauri/tauri.conf.json utilise un seul frontend/dist pour deux besoins incompatibles :

  • build.frontendDist: "../../frontend/dist" + beforeBuildCommand: "npm --prefix ../frontend run build" → vite build sans VITE_TRANSPORT → bundle desktop (transport tauri).
  • bundle.resources: { "../../frontend/dist": "web" } → ce même bundle desktop est packagé en ressource web/.

Or resolve_web_root() (crates/app-tauri/src/embedded_server.rs:498-517) sert resource_dir.join("web"). Le serveur embarqué sert donc le bundle desktop au navigateur.

Le transport est figé au build par Vite : resolveTransport() (frontend/src/app/di.tsx:39-46) lit import.meta.env.VITE_TRANSPORT, constant-folded à la compilation.

Preuve dans frontend/dist/assets/index-nl-2Eu6U.js (build du 2026-07-17 08:00) :

function Cb(){return"tauri"}   // resolveTransport() figé sur tauri

Les deux jeux d'adapters sont bien présents dans le bundle, mais le sélecteur ne pointera jamais sur createHttpWsGateways().

Attendu

L'AppImage doit packager en ressource web/ un bundle construit avec VITE_TRANSPORT=http, distinct du frontendDist desktop. Un seul dist ne peut pas servir les deux transports.

Contexte

  • docs/server-client-mode-remote.md documente déjà que le build web doit être produit en VITE_TRANSPORT=http, sinon exactement ce symptôme.
  • Le carnet de #13 avait classé ce symptôme en « erreur de commande de test, pas un bug de code » — vrai à l'époque de idea --serve --web-root, mais le packaging AppImage de #66/#68 réintroduit le problème par défaut.
  • #66 L4 anticipait le besoin (« produire les assets client Vite en VITE_TRANSPORT=http … packager dans /usr/share/idea/web ») ; la conf actuelle ne le fait pas.
  • npm, jamais pnpm (mémoire frontend-uses-npm-not-pnpm).

Workaround live

Build séparé + IDEA_WEB_ROOT (premier candidat de resolve_web_root, court-circuite la ressource packagée) :

cd frontend && VITE_TRANSPORT=http npx vite build --outDir dist-web --emptyOutDir
IDEA_WEB_ROOT=…/frontend/dist-web ./IdeA.AppImage

DoD

  • Build AppImage produit une ressource web/ en transport http, frontendDist desktop inchangé.
  • Vérif automatisable : le bundle servi ne doit pas résoudre le transport sur tauri.
  • Validation live navigateur derrière reverse proxy : UI + projets listés, aucune erreur __TAURI_INTERNALS__.
  • Rebuild AppImage livrable pour test utilisateur.