Los cinco errores de la primera tarde

1 · El comando no está registrado

Síntoma. El frontend llama a invoke y la promesa se rechaza con un mensaje sobre un comando que no se encuentra. En Rust no hay ningún error: la función está ahí, compila, y no se ejecuta nunca.

Causa. Escribiste la función con su atributo y olvidaste añadirla a la lista del manejador. Son dos sitios y el compilador no relaciona uno con otro: una función con #[tauri::command] que nadie registra es, sencillamente, una función que no se usa.

#[tauri::command]fn cargar_proyecto(id: String) -> Result<Proyecto, ErrorPayload> { ... }// Y aquí, que es lo que se olvida:.invoke_handler(tauri::generate_handler![greet, cargar_proyecto])//                                              ^^^^^^^^^^^^^^^

El arreglo de raíz. Es el fallo más reportado del framework, y el nivel 19 lo elimina: con la generación de bindings, registrar y tipar son el mismo acto, así que un comando sin registrar no produce un binding y el frontend ni siquiera compila.

2 · Los argumentos no llegan

Síntoma. El comando se ejecuta —lo confirmas con un println!— pero los argumentos llegan vacíos, o la llamada falla con un error de deserialización que menciona un campo que tú creías estar enviando.

Causa. El puente convierte entre convenciones de nombres. Un argumento que en Rust se llama file_path viaja como filePath.

#[tauri::command]fn abrir(file_path: String) { ... }

await invoke('abrir', { filePath: '/tmp/x' });   // ✓await invoke('abrir', { file_path: '/tmp/x' });  // ✗ no llega

El arreglo. Enviarlo con la convención de JavaScript. Se puede cambiar ese comportamiento por comando si te interesa mantener los nombres tal cual, y el nivel 14 explica cómo y cuándo conviene. Con bindings generados el problema desaparece, porque la función que llamas ya trae los nombres correctos.

3 · La ventana está en blanco

Síntoma. La aplicación arranca, la ventana existe, y dentro no hay nada. En desarrollo funcionaba.

Causa. Casi siempre una de tres, y conviene descartarlas en este orden:

El arreglo. Abrir las herramientas de desarrollo de la webview y leer la consola. La ventana estará en blanco pero la consola casi siempre dice exactamente qué falló. El nivel 55 explica cómo abrirlas en cada plataforma, incluso en una versión compilada.

4 · Se queda esperando al servidor de desarrollo

Síntoma. El comando de desarrollo imprime que está esperando a la URL y no avanza, o la ventana abre con un error de conexión rechazada.

Causa. El puerto de devUrl en la configuración y el puerto real de tu servidor de desarrollo no coinciden. Ocurre sobre todo cuando el servidor elige otro puerto porque el configurado estaba ocupado: tu frontend arranca tan contento en el siguiente puerto libre y Tauri sigue mirando al primero.

El arreglo. Fijar el puerto en la configuración de tu herramienta de frontend y hacer que falle si está ocupado, en vez de que se mueva en silencio:

// vite.config.js — fijo, y sin buscar otro puerto si está ocupadoexport default {  server: { port: 1420, strictPort: true },};

Un puerto que se mueve solo es cómodo cuando desarrollas webs y es una fuente de fallos cuando otro proceso depende de él.

5 · El plugin no hace nada

Síntoma. Añades un plugin —diálogos, sistema de ficheros, el que sea—, lo registras en el builder, llamas a su API desde el frontend, y la llamada se rechaza con un error de permisos. O peor: no pasa nada.

Causa. Instalar un plugin son tres pasos y casi siempre se hacen dos:

El arreglo. El CLI tiene un subcomando que hace los tres pasos a la vez, y es la forma recomendada de añadir un plugin oficial:

bun run tauri add dialog

Aun así conviene abrir el fichero de capabilities después y comprobar qué te ha añadido: es el documento que define la superficie de tu aplicación, y merece leerse cada vez que cambia.