`instant-meilisearch` geosearch overwrites `objectID`

[queer]

Description
I have an index I am using geosearch on, using instant-meilisearch + react-instantsearch. Something I noticed is that when I try to use hit.objectID for anything, it's never the actual value that's stored in my Meilisearch index or the value returned in the network requests, but instead always a seemingly-random number. Today I traced it down to adaptGeoResponse explicitly overwriting the objectID field:

meilisearch-js-plugins/packages/instant-meilisearch/src/adapter/search-response-adapter/geo-reponse-adapter.ts

Lines 7 to 16 in bc9b833

	const objectID = `${i + Math.random() * 1000000}`
	if (hits[i]._geo) {
	hits[i]._geoloc = hits[i]._geo
	hits[i].objectID = objectID
	}
	if (hits[i]._formatted?._geo) {
	hits[i]._formatted._geoloc = hits[i]._formatted._geo
	hits[i]._formatted.objectID = objectID
	}

It seems that this behaviour has been a part of the geo-response-adapter since the beginning: ac69707#diff-b1f517006a5289a6c011e39668cc44e828b73d2056a2ff00cf04e01bc4bfcafcR13

Expected behavior
instant-meilisearch doesn't change the data I get back from Meilisearch.

Current behavior
instant-meilisearch changes my objectIDs to unwanted, useless values. I have to use a workaround of getting the value from hit._highlightResult.objectID.value.

Screenshots or Logs

[curquiza]

Hello @queer
Thanks for the report

Indeed, that's an issue. However, with @brunoocasali we don't know what would be the best way to fix this.
Do you?

Pinging @flevi29 if you are around too 😇

[queer]

Digging a bit further, I found the justification for why this behaviour exists: #543 (comment)

InstantSearch requires an unique identifier for every marker on the Google Maps. Without that ID the geo point is ignored. Since algolia always provide the same id field :objectID but we don't as they might change from one dataset to the other. So we created a randomly generated id

It makes perfect sense why this would happen, I just wouldn't expect it to overwrite objectID if there already is an objectID present; presumably? datasets that contain an objectID field wouldn't have duplicates.