Skip to content

User.last_login not persisted on successful sign-in #59

@rrrodzilla

Description

@rrrodzilla

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

  1. Start schemaforge with the standard User schema.
  2. POST /auth/login with valid creds (returns 200, token, and emits audit.event.kind=auth.login.success to the tracing pipeline).
  3. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions