IdeA/issue.md at aec4293750270a7ad17218278ba82e097eb88ba7

Files

Blomios 4de25d2bce chore(ideai): état runtime du ticket #74 (passage en QA)

Enregistre le passage de #74 en statut QA (issue, carnet, index) et
l'accusé de complétion des rendez-vous headless du lot.

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

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-07-17 10:34:24 +02:00

3.4 KiB

Raw Blame History

id, number, title, status, priority, sprint, links, agentRefs, createdBy, updatedBy, createdAt, updatedAt, version

number

title

status

priority

sprint

links

agentRefs

createdBy

updatedBy

createdAt

updatedAt

version

249bb0de-118f-4d6f-b0c4-1d4e2aadd83f

Le serveur embarqué sert le bundle desktop (Tauri) au navigateur — __TAURI_INTERNALS__ undefined

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

1784272247901

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.

3.4 KiB Raw Blame History