Multiple bugs in Create Observation entities with dataArray

[S-Panta]

Post request to /sensorthings/v1.1/CreateObservations have multiple bugs. I have manually tested few scenerios and noticed few bugs.

This has been tested with the local build of hydroserver with django-ogc-sensorthings-1.2

curl --location 'http://127.0.0.1:8000/api/sensorthings/v1.1/CreateObservations' \
--header 'accept: */*' \
--header 'X-Api-Key: T8QqUHDAuWLWrW6rutXUBwQmKyAWgFbZ4ItG3XIuO1vGD-c3VPSJgIo' \
--header 'Content-Type: application/json' \
--data-raw '[
    {
        "Datastream": {
            "@iot.id": "019eae3f-3450-70db-b5d2-a55879b4d681"
        },
        "components": [
            "phenomenonTime",
            "result"
        ],
        "dataArray": [
            [
                "2026-06-30T23:33:00+00:00",
                1000
            ]
        ]
    }
]'

• Creating same observation multiple time returns status code of 201 (created) with [error] body. The status code mustn't be 201.
• Suppose I created list of observation with data as follows:

[
    {
        "Datastream": {
            "@iot.id": "019eae3f-3450-70db-b5d2-a55879b4d681"
        },
        "components": [
            "phenomenonTime",
            "result"
        ],
        "dataArray": [
            [
                "2026-06-30T23:39:00+00:00",
                1500
            ],
            [
                "2026-06-30T23:40:02+00:00",
                4500
            ]
        ]
    }
]

Then if I try to create an observation with dataarray by keeping first data as same and updating second array, the specification says the response should be

[
  "http://examples.org/v1.1/Observations(1)",
  "error",
  "http://examples.org/v1.1/Observations(2)"
]

But this is not the case with the api. Any new data therefore send with existing data, the service will return with [error] body and doesn't update new data - which is opposite of what ogc specify.

• posting with data array as empty list result in 201 status code.

• posting with components with empty array and data array as empty list result in 201 status code. However, if there are values in dataarray, posting with empty component gives 422 status code which is okay.

• post with wrong datastream id also give 201 but error as body (which is I guess what ogc specifies which feels very werid) and no observation data is updated in the server.

There could be more multiple cases here that might give more error.
I may either have misunderstood the specification regarding it's proposal of using 201 status code but it seems like every unfriendly reuqest gives 201 status code which isn't the correct HTTP status code response

[S-Panta]

Summary of my finding

#	Scenario	Request Details	Expected Behavior	Actual Behavior	Issue
1	Duplicate observation creation	Same observation (Datastream + phenomenonTime + result) posted twice	Non-201 status code (e.g. 400/409/207) since the item failed to be created, with "error" in response body	Returns 201 Created with ["error"] body	Status code is misleading
2	Partial success in dataArray (one duplicate, one new)	dataArray with 2 rows: 1st duplicate of existing observation, 2nd new/updated	Per OGC spec, mixed response array: ["error", "http://.../Observations(2)"] — new row created, duplicate flagged	Entire request treated as failure — full ["error"] body, new row also not persisted	Violates spec's partial-success handling; valid data silently dropped
3	Empty dataArray	"dataArray": []	Should likely return an error status (nothing to create)	Returns 201 Created	No validation for empty payload
4	Empty components + empty dataArray	"components": [], "dataArray": []	Should return an error status	Returns 201 Created	Same as 3 — empty request accepted as success
5	Invalid/nonexistent Datastream ID	Valid dataArray, bad @iot.id	Per OGC spec: 201 with "error" body (spec explicitly allows this)	Returns 201 Created with ["error"] body, no data written	Matches spec, but counterintuitive

[kjlippold]

@S-Panta Thank you for bringing these up. There's some gaps in the SensorThings v1.1 specification, especially around the data array extension so I'll try to address them as best as I can.

1. The SensorThings v1.1 spec says to return a 201 Created response with "error" in the response body for any observations that can't be created. It doesn't say to do anything differently if all observations in the request happen to fail, or if the payload contains no observations. I agree that it's misleading, but it's compliant with the spec as written.
2. HydroServer performs a bulk insert to handle CreateObservations requests rather than creating each observation one by one. As a result, all observations in these requests either succeed or fail as a group. The spec allows for partial success responses with mixed outcomes, but doesn't require them. So even though HydroServer doesn't take advantage of that, it's still compliant with the spec as written. Implementing partial success would result in significantly slower response times for CreateObservations requests containing large numbers of observations.

3, 4, and 5. See point 1. The spec doesn't provide guidance for these situations, so we fall back to what it does say. It's not very intuitive, but it's still compliant with the spec as written.

Point 4 is a bit more nuanced since components should always include at least "result", or the request will fail. But even then, the response for {..., "components": [], "dataArray" [[]]} would be 201 ["error"] because there was no result (but there was an empty observation in the payload), and for {..., "components": [], "dataArray" []} the response is 201 [] because there was no observation in the payload to return "error" for. It's technically consistent with the behavior of the other examples; it's just confusing because the spec doesn't provide a mechanism to communicate an error in that specific case.

[S-Panta]

Thanks for clarification. Make sense to do atomic operation. The spec should have expanded on the error case or multi status code response would have make more sense. Then, we can close this issue as "correct according to specs" - so not a bug