See #1184 for test proving it.
Seems like either it should dedupe or 400. Off the top of my head I can't think of big downsides to deduping. I guess it would be nice to know on the client if your logic is producing such duplicates. On the other hand it's more user friendly to simply not error when you don't have to, and logically duplicates can be collapsed down without any loss of meaning, so it seems fine.
Could drop a dedup_by here with the same function as the sort.
|
new_assignments.sort_by(|r1, r2| { |
|
(&r1.role_name, r1.identity_id) |
|
.cmp(&(&r2.role_name, r2.identity_id)) |
|
}); |
The spec for PUT says you're supposed to get back roughly what you put in.
A successful PUT of a given representation would suggest that a subsequent GET on that same target resource will result in an equivalent representation being sent in a 200 (OK) response.
https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.4
Personally I don't feel the above deduping would violate the equivalent requirement. I'm surprised the RFC doesn't define it, though.
See #1184 for test proving it.
Seems like either it should dedupe or 400. Off the top of my head I can't think of big downsides to deduping. I guess it would be nice to know on the client if your logic is producing such duplicates. On the other hand it's more user friendly to simply not error when you don't have to, and logically duplicates can be collapsed down without any loss of meaning, so it seems fine.
Could drop a
dedup_byhere with the same function as the sort.omicron/nexus/src/db/datastore.rs
Lines 3649 to 3652 in c451365
The spec for PUT says you're supposed to get back roughly what you put in.
https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.4
Personally I don't feel the above deduping would violate the
equivalentrequirement. I'm surprised the RFC doesn't define it, though.