Archivos, colas y tareas en segundo plano

En el panel, el inquilino lo fija el middleware al empezar cada petición y lo borra al terminar. Un trabajo en cola no pasa por ahí: lo toma un proceso que atiende un trabajo tras otro sin reiniciarse, y todo lo que quedó guardado en una variable estática del trabajo anterior sigue ahí cuando empieza el siguiente.

Por eso un trabajo tiene que llevar en su propia carga el identificador del inquilino para el que se encoló, fijarlo al empezar y limpiarlo al terminar, pase lo que pase. Si un trabajo arranca sin inquilino, lo correcto es que falle y avise, no que siga con lo que encuentre: un error ruidoso se arregla, un cruce silencioso se descubre cuando un cliente se queja.

Abre ContextoInquilino.php, EnviarResumenDiario.php y GenerarRemision.php. Luego lee registro-cola.txt: cada línea de inicio dice quién encoló el trabajo y qué inquilino estaba activo en el proceso cuando empezó. Busca el trabajo que generó la remisión del pedido de la queja y fíjate en el que corrió justo antes en el mismo proceso.

El trabajo buscó el pedido por número con el filtro del inquilino activo. Lee numeracion.txt para saber si ese número existe en más de un cliente, y cruza el inquilino con el que corrió el trabajo con inquilinos.txt.

Arreglar el contexto no basta. Mira la ruta con la que GenerarRemision.php guarda el PDF y con la que DescargarRemision.php lo entrega: solo lleva el número del pedido, y ese número se repite entre clientes. Dos clientes con el mismo consecutivo escriben el mismo archivo, y el último en escribir gana. En un almacenamiento compartido, la ruta de todo archivo de un cliente empieza por su identificador de inquilino, y la descarga comprueba que el prefijo coincide con el de la sesión.

Revisa registro-almacenamiento.txt antes de la madrugada de la queja.

En el mismo registro de la cola hay un trabajo que falló dos veces por no tener inquilino. El equipo quiere «que ese trabajo deje de fallar» y lo pone en la misma lista que la remisión cruzada.