[TASK] Check if subscription manager behaves atomically or not

[MericFeyz]

No description provided.

[wagmarcel]

Test:

1. Stop the NGSI-LD-Update bridge to avoid duplications
2. Create two objects and subscribe to their changes
3. Update the objects in two update rest calls and watch the subscription behavior (e.g. is it updated iteratively or in one step?)j
4. Update the object in one batch REST call and watch the subscription behavior(there should be only one single update)
5. Do the same test with two properties in the same object

[MericFeyz]

Unfortunately Scorpio v5.0.5 does not behave atomically.

Experiment 1

• Create 2 Entities in two individual create requests
• Subscribe to both of them with one subscription observing all entities of their type
• Update 2 Entities in two individual update requests
• Save the notifications to a temp file
  This experiment results in 2 consequent notifications:

{"body":{"id":"notification:-8443402073510220638","type":"Notification","subscriptionId":"urn:subscription-test:1","notifiedAt":"2025-01-10T13:51:28.764000Z","data":[{"id":"urn:plasmacutter-test:12345","type":"https://industry-fusion.com/types/v0.9/plasmacutter_test","https://industry-fusion.com/types/v0.9/state":{"type":"Property","datasetId":"urn:cutter:test1","value":"OFF"}}]}}
{"body":{"id":"notification:-8264387462205091685","type":"Notification","subscriptionId":"urn:subscription-test:1","notifiedAt":"2025-01-10T13:51:30.825000Z","data":[{"id":"urn:plasmacutter-test:123456","type":"https://industry-fusion.com/types/v0.9/plasmacutter_test","https://industry-fusion.com/types/v0.9/state":{"type":"Property","datasetId":"urn:cutter:test12","value":"OFFF"}}]}}

Experiment 2

• Create 2 Entities in two individual create requests
• Subscribe to both of them with one subscription observing all entities of their type
• Update 2 Entities in one batch update request
• Save the notifications to a temp file
  This experiment results in 2 consequent notifications(note that even though the notifiedAt dateTimes are very close to each other, are not identical) :

{"body":{"id":"notification:-5635763728599355493","type":"Notification","subscriptionId":"urn:subscription-test:1","notifiedAt":"2025-01-10T13:55:01.909000Z","data":[{"id":"urn:plasmacutter-test:123456","type":"https://industry-fusion.com/types/v0.9/plasmacutter_test","https://industry-fusion.com/types/v0.9/state":{"type":"Property","datasetId":"urn:cutter:test12","value":"OFFF"}}]}}
{"body":{"id":"notification:-5406380717777676753","type":"Notification","subscriptionId":"urn:subscription-test:1","notifiedAt":"2025-01-10T13:55:01.916000Z","data":[{"id":"urn:plasmacutter-test:12345","type":"https://industry-fusion.com/types/v0.9/plasmacutter_test","https://industry-fusion.com/types/v0.9/state":{"type":"Property","datasetId":"urn:cutter:test1","value":"OFF"}}]}}

Experiment 3

• Create one Entity in one individual create request
• Subscribe to the entity with one subscription observing all entities of their type
• Update the same Entity's same attribute two times in one batch update request (e.g. e.State = b && e.State = c)
• Save the notifications to a temp file
  This experiment results in 2 consequent notifications(note that even though the notifiedAt dateTimes are very close to each other, are not identical) :

{"body":{"id":"notification:-7864066569800536915","type":"Notification","subscriptionId":"urn:subscription-test:1","notifiedAt":"2025-01-10T14:11:30.623000Z","data":[{"id":"urn:plasmacutter-test:12345","type":"https://industry-fusion.com/types/v0.9/plasmacutter_test","https://industry-fusion.com/types/v0.9/state":{"type":"Property","datasetId":"urn:cutter:test1","value":"OFF"}}]}}
{"body":{"id":"notification:-8223072282231665073","type":"Notification","subscriptionId":"urn:subscription-test:1","notifiedAt":"2025-01-10T14:11:30.629000Z","data":[{"id":"urn:plasmacutter-test:12345","type":"https://industry-fusion.com/types/v0.9/plasmacutter_test","https://industry-fusion.com/types/v0.9/state":{"type":"Property","datasetId":"urn:cutter:test1","value":"OFFF"}}]}}

Experiment 4

• Create one Entity with two attributes in one individual create request
• Subscribe to the entity with one subscription observing all entities of their type
• Update the Entity's each attribute once in one batch update request (e.g. e.State = b && e.HasFilter = c)
• Save the notifications to a temp file
  This experiment results in 2 consequent notifications(note that even though the notifiedAt dateTimes are very close to each other, are not identical):

{"body":{"id":"notification:-7764834395620727608","type":"Notification","subscriptionId":"urn:subscription-test:1","notifiedAt":"2025-01-10T14:15:56.594000Z","data":[{"id":"urn:plasmacutter-test:12345","type":"https://industry-fusion.com/types/v0.9/plasmacutter_test","https://industry-fusion.com/types/v0.9/hasFilter":{"type":"Relationship","object":"urn:filter-test:12345"},"https://industry-fusion.com/types/v0.9/state":{"type":"Property","datasetId":"urn:cutter:test1","value":"OFF"}}]}}
{"body":{"id":"notification:-7634862594722572275","type":"Notification","subscriptionId":"urn:subscription-test:1","notifiedAt":"2025-01-10T14:15:56.600000Z","data":[{"id":"urn:plasmacutter-test:12345","type":"https://industry-fusion.com/types/v0.9/plasmacutter_test","https://industry-fusion.com/types/v0.9/hasFilter":{"type":"Relationship","object":"urn:filter-test:1234567"},"https://industry-fusion.com/types/v0.9/state":{"type":"Property","datasetId":"urn:cutter:test1","value":"OFF"}}]}}

To sum up, these experiments, especially the experiment 4, are able to show that the Scorpio applies batch merge operations sequentially and not atomically. The proof of it is the fact that the first notification of experiment 4 reflects the changes of the e.State = b change but not the e.HasFilter = c, and that the second notification reflects both of these changes.

One slight ray of hope is that the Scorpio's minor version update of yesterday mentions fixes regarding notifications. I will conduct these same experiments on v5.0.6 and report.