The following is not really an issue in the sense of malfunction, but more about logic or "cleanness".

Lets say we have the endpoints /api/notes and /api/notes/{id} which acting on all CRUD operations. The records created by this endpoints always belonging to the current user, so the CurrentFeUser() serializer is used on a $user attribute. In this way, the user property is always shown in the response data-structure, which is "useless" as it is always the user itself.

Adding Exclude() to the property does not work, as it disables all serialization and will return NULL for getUser() than (which is expected, sure!). Also using serialization-groups doesn't work, as the $user attribute could be omitted in collection and item GET responses, but has to be set for POST and PUT (other wise user is NULL again). The latter case would make trouble in the front-end code as well, as the object structure varies (user attribute is sometimes there, sometimes not)

For now we keep the user attribute in all responses and ignore it in the front-end. Like I said, its not an issue, but maybe an improvement for a later versions. Maybe it is even possible, that the property where CurrentFeUser() is used on excludes itself in the response (but will be there for the internal database handling). If someone really wants to include the user, an explicit Include() needs to be set or so...