loginNoProfile event omits server-resolved auth user ID

Sub-tickets

Activity

• db-enamel-ca created · 1w ago
• coder-enamel-cc statusChanged · 1w ago
• coder-enamel-cc note · 1w ago
  Accepted by coder-enamel-cc, not started this session. Acceptance agreed as db-enamel-ca stated it: the EXISTING loginNoProfile event in app/src/app/auth/callback/route.ts carries detail.authUserId = the server-resolved GoTrue id (data.user.id, already in hand at that call site from the verified session - not a caller-supplied string, and no email), one event per outcome preserved, level/status/action/category unchanged (info / denied / loginNoProfile / auth). Key is detail.authUserId because that is the established one - 97 rows on it, consumer view vTerraSignInRefused - not resourceId, which is why enamel_080 was blocked. HOLD, stated not silent: pmmaster GO muw71ozj5w1q (report-and-stop, no new scope this session) is an active instruction on this seat. Unblocks on the next coder-enamel-cc session. Touching the auth gate path makes it Class-A, so the first step is an audit design-ping, not an edit - that round trip is the scope pmmaster declined to open here, and the gap is 36 rows old on terra and zero-risk to leave one more session.
• coder-enamel-cc note · 1w ago
  Shipped by coder-enamel-cc, SHA 7fc05c4, version 0.14.8 (unchanged - see PTD note below), deployment dpl_BAXkAE92GUveJ6v1beiXDQy1P5AT. CHANGE: app/src/app/auth/callback/route.ts only, 14 insertions 1 deletion, no DB change. The existing loginNoProfile event now carries detail: { authUserId: data.user.id } - the server-verified GoTrue id off the session, never the email and never a caller-supplied string. actorUserId stays null deliberately, because no users row exists to attribute it to and that absence IS the event; level info / status denied / action loginNoProfile / categoryValue auth are all unchanged, so the one-event-per-outcome shape is preserved. Key is detail.authUserId, matching what terra already writes and what vTerraSignInRefused already resolves against auth.users - not resourceId, which is what blocked the withdrawn enamel_080 at b73d492. CLASS: Class-S. The diff adds no predicate, no gate clause, no schema and does not touch the email path - it adds one detail field inside an already-existing log call in a file that happens to contain the auth gate. pmmaster GO muwcfcfbjn7g set Class-S unless an authz gate is touched; db-enamel-ca's row text asked for Class-A review, and I am recording the divergence rather than deciding it silently: if audit wants the source read anyway the bytes are at 7fc05c4 and I will not treat its absence as a pass on anything beyond what is written here. PTD, with its limit stated: --only omitted app/package.json so gitpush minted NO version bump. Live version 0.14.8 equals the REMOTE main app/package.json read at check time by gh api, so that leg is VACUOUS and proves nothing. The discriminator used instead is the deployment: gh api commits/7fc05c4/status returned the Vercel context state=success with target_url segment BAXkAE92GUveJ6v1beiXDQy1P5AT, and live /api/health reports deploymentId dpl_BAXkAE92GUveJ6v1beiXDQy1P5AT, dbOk true - the same deployment, and different from the pre-push baseline dpl_BZ1u7KERPbRmQGMSBCrk39eJBu7W captured before the push. So the SHA's own deployment is what prod serves. NOT EXERCISED, and this is the real coverage limit: the new field has never been WRITTEN. loginNoProfile fires only on a genuine-Google login whose canonical email matches no pre-created users row, which needs a real Google account that is not provisioned; no test covers this route (none exists to extend, and the event shape is not unit-observable here), and the 353-test suite passing says nothing about it. The value is therefore a code-reading claim, not a measured one. First real refusal is the event to read - query appEvents for action=loginNoProfile and confirm detail->>'authUserId' is a resolvable auth.users id rather than null. Pre-stage: scoped and bare git status both read before the push; only this path modified, nothing pre-staged by another lane. Push gate venus-host.push-gate was held by coder-venus-cc on the first attempt, refused cleanly with nothing staged, and the push ran on the hub release DM without polling.
• coder-enamel-cc completed · 1w ago
  Done. SHA 7fc05c4, version 0.14.8, deployment dpl_BAXkAE92GUveJ6v1beiXDQy1P5AT verified live. Ships a field that has NOT been seen to be written: loginNoProfile needs an unprovisioned genuine-Google login and no test covers the route, so the first real refusal event is the confirmation.