{
  "id": 765401,
  "title": "You know what's worse than not being able to log in?",
  "url": "https://urgent.news/2026/08/13/you-know-whats-worse-than-not-being-able-to-log-in",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-08-13T12:38:44.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/ujja/you-know-whats-worse-than-not-being-able-to-log-in-5379"
  },
  "original_language": "en",
  "account": "The worst part of not being able to log in is when the system appears to work fine, only to reveal its true issues when the user actually tries to use their account. This particular bug, which was part of DEV's Summer Bug Smash, was a cunning deception. The application, built with a serverless .NET backend on AWS Lambda, a SQL Server database, and an Angular frontend, utilized AWS Cognito for authentication, SES and SNS for transactional emails, SMS messages, and verification codes.\n\nThe authentication setup was complex, with two Cognito User Pools, each serving a different purpose. One handled the newer authentication experience, while the other managed older flows, including signup using a mobile number. However, despite this complexity, the application worked well until users attempted to use their accounts.\n\nThe problem arose in the partner and dependant journey, where a member could create a partner or dependant either during signup or later from the member details area. When this happened, a background task, SendingEmailsAfterApprovalBot, was triggered. This task ran every 15 minutes, creating a significant gap between the approval and the actual creation of the necessary Cognito user and onboarding information.\n\nThe critical moment occurred when a partner changed their name five minutes after being approved. While this change was harmless, it caused a discrepancy between the database's latest username and the one used by Legacy Cognito, which still had the old username. Cognito rejected the new user creation because the email address was already associated with an existing user in Legacy Cognito.\n\nThe application attempted to create the user with the updated username, but Cognito couldn't do it due to the existing user with the old username. Cognito usernames are immutable, so the database couldn't simply change the username. The result was a single human represented in two systems with different usernames, leading to authentication issues.\n\nThe deceptive part of the bug was that the user received the expected email and SMS, and the background task ran without any dramatic failure messages. The system looked healthy from the outside, but the discrepancy between the systems caused the user to be unable to log in, even though everything appeared to be working correctly.",
  "summary": "This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry . You know what's worse than not being able to log in? Being told everything worked right up until you try to actually use your account. That was the bug. And, somehow, once again, I ended up being pulled into my favourite corner of software engineering: authentication. At this point, I'm beginning to suspect…",
  "key_points": [
    "Bug disguised as working system",
    "Two Cognito User Pools with different purposes",
    "Delayed user creation caused login issues"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}