Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

ServerCommit no longer enforces required properties on JSON deserialization (regression rc.241 → rc.266)

Abierto
#104 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 4 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
55/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
csharp
Área
api, backend

Línea de trabajo

Comienza con ServerCommit en las versiones de SIL.Harmony.Core.dll y reproduce la salida de JsonSchemaExporter y el comportamiento de deserialización para un payload al que le falta clientId. Compara las rutas de constructores utilizadas por System.Text.Json, incluido el nuevo constructor sin parámetros de rc.266. Se considera terminado cuando las propiedades requeridas omitidas vuelvan a causar JsonException durante la deserialización sin romper ningún escenario de materialización requerido.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

bug

Summary

Between SIL.Harmony.Core 0.2.1-rc.241 and 0.2.1-rc.266, ServerCommit stopped enforcing its required init properties during System.Text.Json deserialization. A JSON payload that omits clientId (and even hybridDateTime) now deserializes successfully, silently defaulting ClientId to Guid.Empty, where it previously threw a JsonException.

ClientId identifies the originating client of a CRDT commit, so accepting Guid.Empty is a data-integrity concern for any endpoint that deserializes commits from clients.

Impact

Downstream, lexbox's CRDT sync endpoint POST /api/crdt/{projectId}/add deserializes ServerCommit[] straight from the request body. With rc.266 a malformed or outdated client can upload commits with a missing/empty clientId and the server will accept them instead of rejecting the request.

Root cause

ClientId is unchanged — still public required Guid ClientId { get; init; } (non-nullable, RequiredMemberAttribute present) in both versions. The only relevant IL difference is that rc.266 adds a parameterless constructor to ServerCommit:

rc.241  ServerCommit ctors: [JsonConstructor] (Guid id, HybridDateTime hybridDateTime); (Guid id)
rc.266  ServerCommit ctors: [JsonConstructor] (Guid id, HybridDateTime hybridDateTime); (Guid id); ()   <-- new parameterless ctor

With a parameterless constructor available, STJ constructs the object and sets init properties afterward, and it stops reporting/enforcing the required init property ClientId. This shows up both in JsonSchemaExporter output and in actual deserialization.

Reproduction

Run STJ's schema exporter and a deserialization against each package version's SIL.Harmony.Core.dll:

JsonSchemaExporter.GetJsonSchemaAsNode(opts, typeof(ServerCommit))["required"]

  • rc.241 → ["Id","HybridDateTime","ClientId"]
  • rc.266 → ["Id","HybridDateTime"]

Deserializing a payload with clientId omitted:

{"id":"11111111-1111-1111-1111-111111111111","hybridDateTime":{...},"changeEntities":[]}
  • rc.241 → throws JsonException: ... missing required properties including: 'ClientId'
  • rc.266 → succeeds, ClientId == Guid.Empty

(Note: rc.266 also no longer enforces HybridDateTime, yet the exported schema still lists it as required — the schema and the enforcement have diverged.)

Expected

Deserializing a ServerCommit that omits a required property (e.g. clientId) should fail, as it did in rc.241. If the parameterless constructor is needed (e.g. for EF/materialization), it shouldn't come at the cost of required-property enforcement during JSON deserialization.

Lenguaje dominante
C#
Estrellas
14
Forks
4
Merge medio
5 d 15 h
PR fusionados (30 d)
10

Preparar el entorno

Aún no hemos revisado los archivos de configuración de este proyecto. Empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de sillsdev/harmony

Todos los issues de sillsdev/harmony

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.