taskUid in 0.28

[eelcol]

In version 0.28, the field uid is changed to taskUid for every asynchronous task

uid has been renamed taskUid in the response body returned by every asynchronous task (e.g. index creation, document addition, etc...)

However, if I want to fetch the current status of such a task, I get a response body without taskUid but with uid. It sort of makes sense, because you are getting data of tasks. But it also is not very consistent. Because of this, my code will always have to check if there is a taskUid variable. If there is no such variable, use the uid variable. In my opinion, it would make more sense to also return a taskUid variable in the response body when querying for task(s). That would eliminate the need in the code to check if there is a taskUid or uid in the response body.

[gmourier]

Hi @eelcol

We've made that choice to bring some consistency to the API.

Indeed, when receiving a direct resource response from the API, there is an uid identifier if it's a document, a task, an index, etc..

However, since a write operation is an asynchronous process, you can receive that asynchronous response from multiple endpoints (e.g. on /documents, /indexes, /settings); In that case, using uid is not clear because it does not reflect the direct resource.

My advice is to have two types of objects:

One type is dedicated to the tasks endpoint API (e.g. Task), and one type is dedicated to the asynchronous responses. (e.g. SummarizedTask or AsyncResponse)

In the future, we could introduce additional information in one or the other. Using two different object types makes you more open to changes that might occur if needed.