A late upgrade to Better Auth 1.7 changed account matching from providerId to issuer plus accountId. Existing Account rows had no issuer value, so login lookups quietly returned no matching account instead of throwing an error. Customers started reporting that they could not log in before any monitoring detected a problem.
The issue was fixed by adding issuer as a nullable column, backfilling it, enforcing NOT NULL, and creating a unique index on issuer and accountId. For this setup, credential accounts used local:credential, while OAuth accounts used local:oauth:.
This raised a broader question: how do you detect an external dependency making a breaking behavioral or schema change when the result is an empty lookup rather than an exception? Do standard error and runtime monitoring catch this kind of failure, or is a synthetic login canary the right approach? Also, is there a practical way to get warned about dependency changes before they reach production?
4 Answers
The best protection is testing the assumptions your application makes about the library through its public API. A test that creates an account and then retrieves it through the real login path would likely have caught the 1.7 change in CI. Add similar coverage for session creation, run migrations against a copy of production data, and smoke-test immediately after deployment.
Treat authentication success as a first-class SLI instead of watching only for 5xx responses. A synthetic login running every few minutes with a disposable test account can verify the redirect, issuer handling, account lookup, and session creation. Alert when it does not return the expected user.
For releases, pin dependency versions, stage upgrades, test migrations in CI, canary new builds, and keep a known-good version ready for rollback.
A normal error monitor probably will not catch this. An empty database result is valid behavior from the application's point of view, so no exception or failed request necessarily occurs. Monitoring needs an expected-outcome check, such as a canary login or a metric for successful authentications and unexpected zero-match lookups.
You generally will not receive a reliable alert from an upstream project before a breaking change reaches you. Changelogs may miss schema assumptions, and even a minor version can alter behavior. Pinning versions and using automated upgrade tests is more dependable than waiting for dependency notifications.
Also verify which dependency version is actually running in the deployed artifact. The production image can differ from the repository, and comparing its build time and version with the first customer report can quickly narrow down the cause.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures