How do you catch silent authentication failures after a dependency upgrade?
Asked by
MellowPine42
A Better Auth 1.7 upgrade recently broke login across my SaaS without producing errors in the application logs or monitoring. The release changed account lookups from using providerId to using issuer and accountId. Existing Account rows lacked the new required issuer value, so authentication queries simply returned no matching account and users were told that their account could not be found.
I fixed the migration by adding issuer as a nullable column, backfilling it, making it required, and adding a unique index:
ALTER TABLE "Account" ADD COLUMN "issuer" TEXT;
UPDATE "Account"
SET "issuer" = CASE
WHEN "providerId" = 'credential' THEN 'local:credential'
ELSE 'local:oauth:' || "providerId"
END
WHERE "issuer" IS NULL;
ALTER TABLE "Account" ALTER COLUMN "issuer" SET NOT NULL;
CREATE UNIQUE INDEX "Account_issuer_accountId_key" ON "Account"("issuer", "accountId");
The bigger concern is how to detect this kind of issue before customers report it. Does ordinary error or runtime monitoring catch an empty lookup when no exception is raised? Is a synthetic login canary that signs in with a test account every few minutes the best approach? Also, how do you protect against dependencies shipping breaking behavior in a minor upgrade—dependency pinning, staged rollouts, compatibility tests, or something else?
Answers
Treat authentication success as a first-class service-level indicator rather than monitoring only server errors. A synthetic login every few minutes with a disposable account can validate the redirect flow, account lookup, issuer handling, and session creation. Alert when the expected user or session is not returned.
For releases, pin dependency versions, test migrations in staging, run post-deploy smoke tests, and canary upgrades before rolling them out broadly. It also helps to keep a known-good build available for quick rollback.
Reply to this answer
Traditional error monitoring usually will not catch this. An empty database result is a valid response, not an exception, so there may be no event for the monitoring agent to report. An authentication canary or an explicit metric for login success and account-not-found rates is the right complement to normal logs and 5xx alerts.
Reply to this answer
The most reliable defense against upstream breaking changes is to test the assumptions your application makes about the dependency. Add integration tests that create an account, retrieve it through the real login path, and create a session. Those tests should have failed in CI when the account-keying behavior changed instead of failing in production.
Also verify which dependency version is actually running before investigating the code. The deployed artifact can differ from the repository or lockfile, and comparing the first customer report with the last build and deployment times can quickly narrow down the cause.
Reply to this answer
Add your answer
Answers are reviewed before publication.
Related Discussions