Source identity
| Field | Recorded value |
|---|---|
| Source type | GitHub source |
| Original record | Janady13/missionmatch / docs/evidence/trackH/item5-last-login.txt |
| Date | Not specified in source |
| Repository | Janady13/missionmatch |
| Revision | 720d47fae476b0d38477ae4401697d372b1ea2bc |
| Branch | feature/opportunity-to-outcome |
| Path or archive member | docs/evidence/trackH/item5-last-login.txt |
| Original SHA-256 | 6809c2c82a5c41793a6cc9a1cba45404c92ad66b93fc028ade2006ae6c724d60 |
| Git blob SHA | 9f5abd02daac04dff2fd14141fe4ac0bdf346c12 |
| Reading-copy SHA-256 | 6809c2c82a5c41793a6cc9a1cba45404c92ad66b93fc028ade2006ae6c724d60 |
Recovered source transcript
Download complete source text ↓67 lines · 3.7 KB
TRACK H ITEM 5, THE LAST LOGIN INSTRUMENT. Evidence, 28 July 2026.
THE REPORT: a design partner said she had logged in and the control plane showed
"never signed in".
THE EVIDENCE THAT SHE WAS RIGHT, from the control plane:
batwood@igotozarks.com sessions=2 active=2 last_login=NULL
joseph.w.anady@gmail.com sessions=135 active=134 last_login=2026-07-21 (STALE by a week)
patriciacox6@aol.com sessions=1 active=1 last_login=NULL <- her login, 28 Jul 08:04
tallen282005@gmail.com sessions=6 active=6 last_login=NULL
trutle973@hotmail.com sessions=1 active=1 last_login=NULL
Four of five accounts held real ACTIVE sessions while the screen said none of
them had ever signed in.
THE CAUSE, internal/modules/auth/service.go line 902:
_, _ = db.Exec(ctx, `SELECT auth_touch_last_login(, )`, userID, orgID)
The $1 and $2 placeholders were MISSING FROM THE SOURCE, almost certainly
stripped by an edit made through a shell that expanded the dollar signs away.
Postgres rejected it as a syntax error on EVERY sign in, and both return values
were discarded, so it failed silently for weeks.
RULED OUT FIRST, each by direct test rather than by reading:
The function exists with the right signature and works: calling it as the
postgres superuser stamped the row.
The app role HOLDS execute: has_function_privilege = true.
Row level security is not the cause: the function is SECURITY DEFINER owned by
missionmatch_migrator, which has BYPASSRLS.
Calling it as the APP ROLE with literal ids stamped correctly.
One intermediate test of mine was INVALID and is recorded as such: passing
subselects as the app role returned NULL under RLS, so the function's NULL
guard returned early and the result looked like a failure that was not one.
THE FIX: placeholders restored, and the failure is now LOGGED. It is still not
allowed to fail the login, because recording a sign in is bookkeeping and denying
entry over bookkeeping would turn a reporting defect into an outage. Zero rows is
also caught explicitly, because Postgres does not treat it as an error and it is
exactly what a silent no op looks like.
PROVEN ON STAGING, two real logins through the live API:
before desk.admin@fg-talent.test last_login=NULL
patriciacox6@aol.com last_login=NULL
after desk.admin@fg-talent.test last_login=2026-07-28 16:19:27.020857-05
patriciacox6@aol.com last_login=2026-07-28 16:19:27.413547-05
POSITIVE CONTROL, as the protocol requires. EXECUTE was revoked from the app role
to break the stamp deliberately:
the login still returned 200, which is correct, bookkeeping must not deny entry
last_login stayed NULL, so the break was real
and the server SAID SO: 1 ERROR line,
"auth: last login stamp failed, the accounts screen will understate this sign in"
Restoring the grant made the next login stamp again at 16:19:54. The instrument
now reports its own failure, which is the whole repair.
PRODUCTION HISTORY BACKFILLED from auth_sessions, the authoritative record of who
actually signed in. UPDATE 5. A diagnostic call of mine had also written a FALSE
timestamp for Patricia (16:16, when her real session was 08:04); the backfill
corrected it rather than leaving my own artifact in the data.
batwood@igotozarks.com 2026-07-27 15:17:12
joseph.w.anady@gmail.com 2026-07-28 11:51:42
patriciacox6@aol.com 2026-07-28 08:04:16
tallen282005@gmail.com 2026-07-27 14:42:49
trutle973@hotmail.com 2026-07-27 16:51:29
STILL TO DO: the code fix is on staging only. Production runs the old binary and
will keep failing to stamp NEW logins until a Track H production deploy is
approved. The backfill above repaired history, not the mechanism.