TCMProject.Messaging 26.9.15.1

• net10.0

  • Microsoft.Extensions.Configuration.Binder (>= 10.0.0)
  • Microsoft.Extensions.Options.ConfigurationExtensions (>= 10.0.0)
  • WolverineFx (>= 6.30.3)
  • WolverineFx.EntityFrameworkCore (>= 6.30.3)
  • WolverineFx.Postgresql (>= 6.30.3)
  • WolverineFx.RabbitMQ (>= 6.30.3)
  • WolverineFx.RuntimeCompilation (>= 6.30.3)

TCMProject.Events: se ELIMINA AppointmentNoShowV1. Era el contrato piloto del bus, elegido a proposito por ser inofensivo -un hecho consumado que nadie consumia con efecto de negocio- para ejercitar outbox, RabbitMQ y consumidor de punta a punta. Cumplio esa funcion: el ciclo completo quedo demostrado por el pipeline de auditoria, que cruza cuatro procesos con un contrato real. Ningun servicio del ecosistema lo referenciaba fuera de scheduleeasycore, y alli solo lo usaban el consumidor de humo y los tests de outbox, que pasan a un contrato de prueba propio. CAMBIO INCOMPATIBLE si alguien lo usaba: las versiones anteriores siguen en nuget.org. AuditChangeRecordedV1 NO se toca. Nota anterior (26.9.10.1) - TCMProject.Messaging: sin TransactionScope, el flush se dispara por el evento SavedChanges del DbContext y no por un ISaveChangesInterceptor del contenedor. Medido: EF Core no descubria ese interceptor desde DI y los sobres quedaban sin soltar en jobs, consumidores y comandos con SkipCommandTransaction. El evento no depende de como se haya registrado el contexto, y este paquete no controla el AddDbContext del servicio. Nota anterior (26.9.9.5) - TCMProject.Messaging: el outbox ENTREGA SOLO tras el commit. Publicar alcanza. Antes, PublishAsync encolaba y el sobre quedaba en la tabla como propiedad del nodo esperando un flush que en algunos caminos no llegaba nunca; el agente de durabilidad no lo tocaba porque solo reclama sobres de nodos MUERTOS. Sintoma: cero errores, la publicacion parece correcta, y la cola no recibe nada mientras el outbox crece. Ahora la garantia vive en el outbox y no en quien publica. Con TransactionScope, PublishAsync se suscribe a TransactionCompleted: eso solo REGISTRA una funcion, no abre conexiones; el flush corre cuando el evento dispara, o sea despues del commit, y solo si Status es Committed. Sin TransactionScope (jobs, consumidores, SkipCommandTransaction), OutboxFlushInterceptor suelta al terminar el SaveChanges, que ahi ya commiteo por su cuenta; EF Core lo descubre solo del contenedor. NO se suelta durante el SaveChanges a proposito: con la conexion de EF abierta, el flush abre una SEGUNDA conexion, .NET promueve a transaccion distribuida y Postgres responde 55000 prepared transactions are disabled, abortando tambien el cambio de negocio. El flush va con TransactionScopeOption.Suppress o intentaria enlistarse en la transaccion recien cerrada. MultiFlushMode AllowMultiples: con el default OnlyOnce, un sobre encolado DESPUES de un flush se descarta en silencio (JasperFx/wolverine issue 1825). NUEVO Outbox:StaleMinutes (10 por defecto) libera los sobres que nadie solto; es la RED y no el camino, alto a proposito para que en operacion normal el outbox este vacio y la metrica de profundidad siga sirviendo de alarma. SaveChangesAndFlushAsync queda OBSOLETO: suelta dentro del TransactionScope, antes del commit final. TCMProject.Audit no cambia. Nota anterior (26.9.9.4) - TCMProject.Utilities: recupera PLATFORM_RESEND_EMAILS=121 en main (publicado en 26.8.25.6 y en uso por tcmadmingateway; las 26.9.x lo habian perdido y rompian la compilacion del gateway). Ademas, permisos de Ulandin (26.9.9.3): ModuleEnum.PLATFORM_ULANDIN (anexado al final, enum sin valores explicitos) y PermissionEnum PLATFORM_VIEW_ULANDIN=122 / PLATFORM_MANAGE_ULANDIN=123, dentro del rango 121-129 reservado para PLATFORM_*; el 121 sigue reclamado por la rama de reenvio de correos. El seeder de tcmaccounts los concede solo a Owner/Administrator de TCM-X al adoptar esta version. Los demas paquetes se republican solo por la version compartida, sin cambios. Nota anterior (26.9.9.2) - TCMProject.Audit: primera version. Log de cambios campo a campo -quien cambio que, cuando, valor anterior y nuevo- para las APIs del ecosistema. Se engancha via DbContextOptions: no hay que tocar ningun handler ni repositorio. Fase 0 del RFC (knowledge-base/platform/infrastructure/audit-trail-design.md). OJO AL ADOPTAR: AddTcmAudit REVIENTA el arranque si Messaging:Enabled=false o Messaging:RabbitMq:Enabled=false. No es capricho: el outbox aguanta que el broker se CAIGA -el sobre queda persistido y se recupera solo- pero SIN transporte configurado Wolverine no encuentra ruta, dispara NoRoutesFor y descarta el mensaje sin persistirlo. Para auditoria eso rompe el requisito 6 y encima en silencio. Un servicio adopta la auditoria DESPUES de tener broker, no antes. La auditoria es opt-in por entidad y por campo (leccion de Salesforce: auditar todo multiplica el volumen de escritura); lo que no se declara con audit.Entity de T o [Audited], no se audita. Deny-list global: RowVersion, AppCreatedBy, AppCreationDate, AppLastUpdatedBy y AppLastUpdatedDate nunca se auditan -son ruido, el encabezado ya los trae- sin ella cada update generaria tres diffs de basura. Valores en JSON invariante, no ToString(), para que un decimal o un DateTime no queden distintos segun la cultura del servidor. Redact() guarda solo el hash; Truncate() guarda hash mas longitud por encima del umbral. FailOpen es el unico modo: un fallo de captura NO tumba la escritura de negocio, se loguea con severidad alta. TCMProject.Events suma los contratos de auditoria (AuditChangeRecordedV1, AuditFieldChange y sus enums) y sigue SIN dependencias, para que TCM.AuditApi pueda referenciarlo sin heredar EF ni el transporte. TCMProject.Messaging no cambia de contenido; se republica porque Audit lo referencia por ProjectReference y la dependencia queda fijada a esta misma version. Verificado con 20 tests, sin Postgres ni RabbitMQ: deny-list, opt-in, redactado, truncado, delete, impersonacion, captura por SavingChanges Y SavingChangesAsync -RepositoryBase.Update usa el sincrono, cubrir solo el asincrono dejaria sin auditar dos servicios enteros-, y que la validacion reviente cuando falta transporte.