Descargar Markdown Documento original en GitHub

Corrección de concurrencia de asignaciones de planes y productos de Launch

Corregido AUTH-03 de la revisión de autorización. Solo se modificaron el servidor de Launch y las pruebas de regresión correspondientes, sin despliegue ni publicación del SDK; los límites de decisión de autorización de Licentivo y del SDK no cambian.

Cambios

Al guardar una asignación, la transacción bloquea primero el registro compartido de producto de Launch y después la versión del plan. Las solicitudes de guardado de distintos planes o procesos respetan así el mismo bloqueo de producto; las solicitudes en conflicto devuelven HTTP 409 PRODUCT_MAPPING_CONFLICT.
products.licentivo_product_id conserva una ruta pública de producto estable. Tras guardar correctamente la primera asignación, los demás planes del mismo producto de Launch solo pueden elegir ese producto de Licentivo; se permite elegir políticas distintas de él. El campo no guarda permisos de funciones, cuotas de dispositivos ni estados de autorización de clientes.
La identidad del cliente lee la ruta estable y ya no elige el producto por la versión máxima de todos los planes. Publicar planes y generar configuración de integración SDK también comprueba la misma vinculación.
Las bases de datos antiguas añaden automáticamente un campo que admite null. Para los datos aún sin campo estable se consultan, por orden, el historial de compras incluidas las pagadas, las publicaciones históricas y las demás asignaciones. Si hay varios productos en la misma prioridad, se señala explícitamente el conflicto, sin adivinar. El único producto comprado tiene prioridad sobre borradores ajenos; guardar después una asignación compatible puede fijar la vinculación. Editar el contenido del producto conserva la vinculación.

Los datos históricos erróneos vendidos a varios productos de Licentivo siguen requiriendo comprobación manual; este cambio no reescribe registros de compra ni licencias remotas. Para usar otro producto de Licentivo se debe crear un producto nuevo de Launch; no se puede reescribir la ruta original usando un plan nuevo.

Consulte la implementación en Guardado de asignaciones, Enrutamiento de productos, Emisión de identidad, Validación de publicación, Comprobación de integración y Modelo de datos.

Verificación local

Comprobación	Resultado
Comparación con la implementación anterior a la corrección	La misma prueba de regresión detecta de forma estable que dos guardados en conflicto tienen éxito a la vez y falla como se esperaba
Regresión específica de asignaciones después de la corrección	De las solicitudes en conflicto, una tiene éxito y la otra devuelve 409; ambos guardados compatibles tienen éxito; los borradores erróneos no afectan a la identidad después de sincronizar el pago; la capa de integración SDK acepta el contexto correcto del producto
Protección de datos históricos	Todo superado: prioridad de la ruta comprada, error por ambigüedad, prohibición de publicar borradores erróneos, imposibilidad de generar configuración SDK desde publicaciones históricas erróneas y conservación de la vinculación al editar contenido
Todos los paquetes de código fuente Go y regresión MySQL	192 registros de pruebas superadas, incluidos subcasos; sin fallos. `TestProductUploadRoundTrip` omitida, no contada como superada
Actualización de la estructura de la base de datos antigua	La inicialización añade el campo que admite null a las estructuras sin columna de enrutamiento; la inicialización repetida funciona
Integración real de Launch, Licentivo y SDK Go	13 fases de negocio superadas, incluidas compras, ejecución de funciones con firmas reales, recuperación tras cierre normal, cierre de sesión, desvinculación remota, generaciones antiguas, renovaciones y reembolsos, revocación de cuentas y rechazo de ejecución después de reembolsos/reversiones
Pruebas adicionales finales	Regresión específica de asignaciones superada en una base de datos vacía nueva, incluidas comprobaciones de configuración de integración de publicaciones históricas; `go vet` superado

Después de completar toda la regresión y la integración con servicios reales, se añadió una comprobación final de coherencia de integración SDK y se volvieron a ejecutar por separado la regresión específica con ese escenario y go vet. El fallo esperado de la implementación antigua demuestra que la prueba detecta la condición de carrera original y no es un fallo de regresión pendiente.

La integración usa un MySQL 8.0.32 local independiente, el servicio Licentivo actual y el SDK Go real; los canales de pago y DeepL usan servicios simulados aislados, sin cargos reales ni traducciones de pago. Las pruebas específicas de concurrencia y asignaciones históricas erróneas usan la lógica de negocio real de Launch, MySQL y un simulador de protocolo; no se afirma que los nueve SDK hayan completado esta ronda de integración con servicios reales.

En esta ronda no se accedió a 192.168.2.177. Los procesos temporales de MySQL y Licentivo iniciados para estas tareas se detuvieron; se conservaron los servicios originales. Los materiales originales están en el directorio ignorado .local/mapping-fix-20261024/; consulte un resumen compartible en las pruebas de verificación.