Description Jan-Luca Kiok 2022-07-15 10:41:54 CEST

Disclaimer: I could only reproduce this for schools so far but I am unsure if this affects other resources too.

Take an env where you have extended attributes that are mapped, configured and already available via Kelvin.
If you update the value of one of these the new value can be gathered by GETing the individual resource, but a GET to all still has the individual resource at it's old state.

Interestingly the problem does not occur for a parametrized general search (request with ?name=testschool) or normal attributes like the displayname.


To reproduce:

GET to https://<FQDN>/ucsschool/kelvin/v1/schools/testschool

{
...
  "udm_properties": {
    "testproperty": null
  }
}

GET to https://<FQDN>/ucsschool/kelvin/v1/schools/

[
  {
    "url": "https://<FQDN>/ucsschool/kelvin/v1/schools/testschool",
    ...
    "udm_properties": {
      "testproperty": null
    }
  }
]


After the update:

GET to https://<FQDN>/ucsschool/kelvin/v1/schools/testschool

{
...
  "udm_properties": {
    "testproperty": "new-value"
  }
}

GET to https://<FQDN>/ucsschool/kelvin/v1/schools/

[
  {
    "url": "https://<FQDN>/ucsschool/kelvin/v1/schools/testschool",
    ...
    "udm_properties": {
      "testproperty": null
    }
  }
]


As a workaround it was sufficient to restart the Kelvin API, afterwards the new value could be retrieved from the general search too.

In my opinion the best would be if the updated value is available instantly for both but if this is unfeasible it would be good if both requests lead to equal responses.