Row GET returns false 404 when linked rows already contain expanded BB user references

Description

On self-hosted Budibase v3.44.0 (v3.44.0-cloud.2 app and worker), GETting an existing row can return:

{"message":"That row couldn't be found","status":404}

The CouchDB document exists and the same row is returned successfully by row search.

Reproduction

A table has bb_reference / bb_reference_single user columns and linked rows. For affected rows:

• direct CouchDB document read: HTTP 200
• Budibase row search: HTTP 200 and includes the row
• GET /api/{tableId}/rows/{rowId}: HTTP 404

The issue is deterministic for the same rows. In one sample of 100 production rows, 32 failed direct GET while all were searchable.

Root cause evidence

Node inspector exception tracing during the failing request shows:

TypeError: t.includes is not a function
  at RedisWrapper.prefixed
  at RedisWrapper.bulkGet
  at cache.user.getUsers
  at fetchUserReferences
  at coreOutputProcessing
  at outputProcessing
  at sdk.rows.find

At the bulkGet frame, the argument passed to cache.user.getUsers() contains:

[
  {"type":"string"},
  {"type":"string"},
  {"type":"object","ctor":"Object","idType":"string","idPrefix":"ro_"},
  {"type":"object","ctor":"Object","idType":"string","idPrefix":"ro_"}
]

The stored values of every bb_reference field in CouchDB were also scanned; they are strings, not objects. The object values are introduced during output enrichment: attachFullLinkedDocs() enriches linked records first, then coreOutputProcessing() collects BB references across the whole enriched structure. Linked rows that have already had user references expanded therefore contribute user objects. getBBReferenceIds() currently returns arrays unchanged, so these objects reach fetchUserReferences() and then Redis bulkGet(), whose key prefixer calls .includes() on the object.

The row controller catches this processing exception and replaces it with the generic row-not-found 404.

Expected behavior

getBBReferenceIds() / reference collection should normalize expanded user objects to their _id before calling cache.user.getUsers(). An existing row should not be reported as missing because linked-row output processing failed.

Additional checks

• Clearing only the disposable Redis cache did not change the result.
• App, worker, CouchDB and Redis remained healthy.
• No CouchDB row/schema/index changes were made.