appEvents writes all fail since 07:53Z: logger-core still INSERTs dropped column path
REGRESSION from VENUS-343 (venus92 applied 07:53:45Z dropped appEvents.path). src/lib/logger-core.ts insertEvent and insertFeedbackEvent still list "path" in their INSERT column lists, so EVERY appEvents write fails since 07:53Z: measured 0 rows after 07:53:45Z vs a 5-minute heartbeat cadence (last row 07:50:00Z). logEvent swallows, so telemetry/error/alert rows are silently lost; logEventTx THROWS, so a transactional audit write (approveAccessRequest userReactivatedOnApprove) rolls back its caller. Caught by schema-contract.test.ts only once db/schema.md was regenerated (VENUS-457) - the committed schema.md was stale and still listed path, so the contract guard was green against a column prod no longer had. Fix: drop path from both column lists, params and KNOWN_FIELDS, and from LogEventInput so tsc rejects any caller.
Activity
-
Pushing hotfix under VENUS_SKIP_PREPUSH=1 for this ONE push. Manual gate run on the same tree: no-silent-failure lint, identity-bind lint passed; vitest 1300 passed / 1 failed / 23 skipped, the ONE failure is scanner-probe-drift (pluto checkout's EVO-115 scanner-probe-vectors.ts at 112 vs vendored 106, a cross-repo state unrelated to this change); tsc 0 errors. schema-contract (which caught this) passes with the fix.
-
PTD dba1b00: Vercel target_url 6GiJzMN1d72mYrejVS3W29CiXfPT == /api/health dpl_6GiJzMN1d72mYrejVS3W29CiXfPT, dbOk true, version 1.17.37. Writes RESUMED: first appEvents row after 07:53:45Z at 08:10:01Z. Census 07:53:45-08:10:30Z: 0 committed writes in every public base table carrying createdAt/updatedAt/decidedAt (accessRequests 0). NOT COVERED: a rolled-back logEventTx caller leaves no row; auth.* unreadable from my role and Vercel runtime logs 403 - auth session read asked of db-venus-cc.
-
USER IMPACT CLOSED (pmmaster-evolutiva-cc-muwejf6u94t1). Arithmetic: jwt_exp=3600 (GoTrue config per pmmaster; DB GUC app.settings.jwt_exp also reads 3600 from my role, a corroborating but separate setting), sessions_timebox=0, sessions_inactivity_timeout=0, refresh_token_rotation_enabled=true -> a session outlives its token only via a refresh. Window A 06:53:00Z-07:53:45Z: 0 sign-ins, 0 refreshes -> every pre-outage token had expired by the drop. Window B 07:53:45Z-08:10:30Z: sessions.updated_at 0, refresh_tokens.updated_at 0, users.last_sign_in_at 0 (db-venus-cc via DATABASE_URL_DIRECT) -> none minted during it. So no valid session existed during the outage; no approval click was possible; nothing to disclose; no user contacted. The zeros alone were NOT sufficient; the token lifetime is what bounds them.
-
CLOSE: fix dba1b00, venus 1.17.37, deployment dpl_6GiJzMN1d72mYrejVS3W29CiXfPT bound to health, dbOk true. appEvents writes failed 07:53:45Z-08:10:01Z (first row after fix 08:10:01Z); those rows are lost, not recoverable. Zero user-facing impact per the token arithmetic above. NOT EXERCISED: any non-session-bearing caller of the appEvents write path (crons, internal bearer routes, watchdog) - their writes in the window were lost silently and are not reconstructed. Follow-ons: VENUS-460 (logEventTx aborts business transactions), grep-before-DROP requirement on VENUS-343, Vercel runtime-log 403 row.
-
completed