Concierge.Auth.Client.Profiles 2.0.0

Concierge.Auth.Client.Profiles

Reads and writes user profiles against AuthService (contract v1.3 §10.7), and consumes thiso.events (user.profile.updated, user.status.changed, user.identity.linked) into the client service's own user entity via a host-supplied IUserProfileMapper<TClientUser>.

Not in scope

PATCH /api/v1/auth/me (contract §4.8) — that is the human self-service route, not a client-credential concern, and is not implemented here.

Install and register

services.AddConciergeAuthClient(configuration, db => db.UseNpgsql(cs, npgsql =>
    npgsql.MigrationsHistoryTable("__EFMigrationsHistory", "concierge"))); // base package — required first
services.AddConciergeSecretManagement(configuration); // Secrets package — required first
services.AddConciergeAuthClientTokens(configuration); // Tokens package — profile HTTP uses Bearer JWT
services.AddConciergeUserProfileSync<MyUser, MyProfileMapper, MyAccessHook>(configuration);
// binds "Concierge:AuthClient:ProfileSync"; TAccessHook is a required type parameter, not optional

HTTP surface

• IUserProfileClient.GetProfileAsync(userId, ct) — GET .../users/{userId}/profile.
• IUserProfileClient.UpdateProfileAsync(userId, request, ct) — PATCH .../users/{userId}/profile. Writable fields are displayName, avatarUrl, and phone — there is no email field, by design (email is the magic-link authentication factor; a writable email would be an account-takeover primitive). avatarUrl and phone use Optional<string?> so "clear it" (null) is distinguishable from "leave it alone" (omitted from the request body); a plain nullable cannot express this and will silently wipe data — this bug class recurred three times in this project (avatarUrl in T-0083, phone in T-0091, and displayName on the inbound event path in T-0092, where it was live and wiping display names on every phone-only update). A 409 VERSION_CONFLICT is never auto-retried — it is surfaced via ProfileUpdateResult with the server's current version so a human can decide; refetching and re-applying would silently clobber a concurrent human edit.
• There is no Idempotency-Key on these routes (contract §10.7 defines none) — a replayed PATCH is not deduplicated by AuthService and is not a no-op at the protocol level; do not build retry logic that assumes otherwise.
• email is read-only everywhere in this package: it appears on the inbound event (UserProfileChanged.Email) purely informationally and has no corresponding writable property on UpdateUserProfileRequest. Known limitation (T-0093, open): email itself is not presence-tracked the way displayName/avatarUrl/phone are — there is no Optional<T> on it, so a mirror consuming this event cannot distinguish "email unchanged" from "email present but not worth carrying" the same principled way it can for the other fields.
• Caveat (pending T-0097): a denial anywhere on the §10.7 routes is uninterpretable — bad credential, missing can_write_user_profile capability, and unknown user all collapse to the same denial shape (contract §10.5). This package cannot tell you which one occurred. A whoami endpoint (contract v1.6 §10.8) will fix this; it has not shipped yet.

Event consumption

AddConciergeUserProfileSync<TClientUser, TMapper, TAccessHook>() registers a background consumer that binds a queue to user.profile.updated, user.status.changed, and user.identity.linked on the thiso.events topic exchange.

• user.profile.updated carries the profile's own version. An incoming version that is lower than or equal to the version already known via IUserProfileMapper<TClientUser>.GetVersion is dropped — RabbitMQ gives no cross-redelivery ordering guarantee.
• user.status.changed invokes IAccessReevaluationHook.ReevaluateAsync synchronously, in-line with message handling — a suspension must not wait for token expiry (contract §6).
• Events are not a durable channel. IProfileReconciler<TClientUser>.ReconcileAsync(userId, ct) fetches via GetProfileAsync and re-applies through the same mapper, to repair a mirror that missed an event.