Observation
The built-in User schema declares a last_login field, but it is never written. After a verified auth.login.success audit event, the field on that user's row remains empty.
Reproduced on schemaforge v0.31.0 against the Meridian production deployment.
Repro
- Start schemaforge with the standard
User schema.
- POST
/auth/login with valid creds (returns 200, token, and emits audit.event.kind=auth.login.success to the tracing pipeline).
GET /entity/User for the user that just logged in.
Expected
last_login is set to the timestamp of the successful login (or, looser: the most recent successful login).
Actual
last_login is empty / null. Confirmed via schemaforge entity list User against a host where admin has logged in many times in the last hour:
id active display_name email last_login ...
user_01kqaz174gf7sr8hgj7mz4c7zy true Administrator admin 9223372036854775807 ["platform_admin"]
...
Every one of the 15 users on this deployment has the same empty last_login, including freshly-logged-in users.
Why this matters
Operators currently have no DB-resident record of who has signed in. The information exists in the tracing/journald audit stream, but:
- Querying "who has actually used the system since launch?" requires a CloudWatch Logs Insights / external-log query rather than a simple
entity list User.
- Onboarding status (has user X completed first-login?) cannot be answered from the entity API — admins have to grep logs.
- The schema advertises a
last_login field, which is misleading if it is never populated.
Suggested fix
When the auth handler emits auth.login.success, also update the matching User row's last_login to the event timestamp. A login_count increment would be a nice addition but is not required.
If there is a reason the field is intentionally not maintained (e.g. write-amplification, audit-immutability concerns), please document that in the User schema so the field can be removed or renamed.
Observation
The built-in
Userschema declares alast_loginfield, but it is never written. After a verifiedauth.login.successaudit event, the field on that user's row remains empty.Reproduced on schemaforge v0.31.0 against the Meridian production deployment.
Repro
Userschema./auth/loginwith valid creds (returns 200, token, and emitsaudit.event.kind=auth.login.successto the tracing pipeline).GET /entity/Userfor the user that just logged in.Expected
last_loginis set to the timestamp of the successful login (or, looser: the most recent successful login).Actual
last_loginis empty / null. Confirmed viaschemaforge entity list Useragainst a host whereadminhas logged in many times in the last hour:Every one of the 15 users on this deployment has the same empty
last_login, including freshly-logged-in users.Why this matters
Operators currently have no DB-resident record of who has signed in. The information exists in the tracing/journald audit stream, but:
entity list User.last_loginfield, which is misleading if it is never populated.Suggested fix
When the auth handler emits
auth.login.success, also update the matchingUserrow'slast_loginto the event timestamp. Alogin_countincrement would be a nice addition but is not required.If there is a reason the field is intentionally not maintained (e.g. write-amplification, audit-immutability concerns), please document that in the
Userschema so the field can be removed or renamed.