lasdf1234 opened a new issue, #12486: URL: https://github.com/apache/gravitino/issues/12486
### Version main branch ### Describe what's wrong `RelationalEntityStore.update` and `updateById` only `cache.invalidate` the name-keyed entry after writing the backend. They do not `cache.put` the updated entity. User/Group name lookups (`getUser` / `getGroup`, used by SCIM `filter=userName eq "..."` and similar) can keep serving the pre-update fields (for example `enabled=true` after PATCH `active=false`) until the cache TTL expires. GET-by-id is not affected because `getById` always hits the backend. The same write path is used by `alterUserById` / `alterGroupById` and by grant/revoke role updates on the user/group entity. Separately, `removeUserByExternalId` / `removeGroupByExternalId` and storage `updateByExternalId` / `deleteByExternalId` have no REST, Java client, or SCIM callers. SCIM looks up by `externalId` and mutates/deletes by Gravitino-assigned id. ### Error message and/or stacktrace N/A. The API returns 200 with the updated entity; a later name-based get/filter still returns the cached pre-update entity. ### How to reproduce 1. Enable entity cache (default). 2. Create a user, then `getUser` so the name-keyed cache is warm. 3. `alterUserById` to set `enabled=false`. 4. `getUser` by name still returns `enabled=true` until TTL if the cache entry was not replaced. ### Additional context Keep `getUserByExternalId` / `getGroupByExternalId`. Keep `OperationType.REMOVE_*_BY_EXTERNAL_ID` so historical audit logs still parse. `put` already writes through the cache; `delete` / `deleteById` already invalidate. This change write-throughs `update` and `updateById` the same way, and removes the unused externalId mutation APIs. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
