[viewer + backend?] Device aggregate moet ook kunnen worden geinstantieerd als DeviceRegistered niet het eerste event van de aggregate is

[marcvanandel]

Blijkbaar is het mogelijk dat een Device ontstaat ... maar dat toch het DeviceRegistered event niet het eerste event is dat wordt opgeslagen in de Eventstore: zie https://github.com/kadaster-labs/sensrnet-home/discussions/305#discussioncomment-2485777

In de projectie zou een Device aangemaakt moeten kunnen worden met elk event. Zodra er een event binnenkort op een aggregate (met een aggregateId) die nog niet bestaat, dan moet deze aangemaakt worden met de informatie die beschikbaar is. Dat is functioneel wellicht niet compleet ... maar wel zoals een client (Registry Node) 'm heeft aangemaakt. De projecties / views volgen hierin gewoon wat daar ontstaat, of dat nou (functioneel) logisch is of niet.

Discussed in https://github.com/kadaster-labs/sensrnet-home/discussions/305

^{Originally posted by **CelineJansen** March 30, 2022} Node Eindhoven 68 sensoren:  Centrale viewer 67 sensoren:  (Ik zou 70 verwachten: 2 van Tilburg in Eindhoven + 68 van Eindhoven). Waar kan dit aan liggen? Het lijkt geen caching te zijn, heb mijn browser geschiedenis verwijderd en het resultaat blijft hetzelfde. Via de API ($(Endpoint)device?legalEntityId=$(OrganisatieID)) krijg ik ze wel alle 68 door.

[kad-busses]

Goed gevonden dat die volgorde niet klopt in de EventStore! Kan bevestigen dat de events ook in de verkeerde volgorde op de chain staan.

Misschien een race condition in de backend? Gezien deze sensoren in bulk opgevoerd waren. Het is 1 enkele API call naar de backend om het device aan te maken, wat 2 events produceert: DeviceRegistered en DeviceLocated. Als het goed is kan die tweede pas opgeslagen worden zodra die eerste bestaat, maar dat zou een startpunt zijn om te kunnen zoeken.

[kad-busses]

Lijkt een effect te zijn van het feit dat de events asynchroon worden verwerkt.

Dit is hoe de device geregistreerd wordt:

    aggregate.registerDevice(
        command.legalEntityId,
        command.name,
        command.description,
        command.category,
        command.connectivity,
        command.location,
    );
    aggregate.commit();

https://github.com/kadaster-labs/sensrnet-registry-backend/blob/main/src/command/handler/model/device/register-device.handler.ts#L18

De events worden samen in de registerDevice klaargezet.

    registerDevice(...) {
        this.simpleApply(new DeviceRegistered(this.aggregateId, legalEntityId, name, description, category, connectivity));
        this.simpleApply(new DeviceLocated(this.aggregateId, location.name, location.description, location.location));
    }

https://github.com/kadaster-labs/sensrnet-registry-backend/blob/main/src/command/aggregates/device.aggregate.ts#L74

Ze worden echter pas (gelijktijdig) gedispatched zodra er gecommit wordt. Hier is het dus denkbaar we de volgorde waarin de handlers de events oppakken niet gegarandeerd is.

[kad-busses]

We hebben zelf wel getest met een grote bulk aan devices opvoeren, wat geen crashes opleverde. We hebben echter, naar mijn weten, nooit gevalideerd of de data ook daadwerkelijk goed opgeslagen werd