The timeout appeared without warning. A migration pipeline that had run fine in staging suddenly ground to a halt in production, throwing lock wait timeouts across multiple worker threads. The application was querying and writing to the same table, and somewhere in that dance of reads and writes, things had seized up entirely. Here is a walk through the investigation, from the first diagnostic query all the way to the fix — along with an explanation of why it worked. Find the blocker The first tool in any SQL Server lock investigation is sys.dm_exec_requests joined against sys.dm_exec_sessions . This query shows you every session that is currently blocked, who is blocking it, and what SQL both parties are running: A second query dug into the exact lock modes held on the specific table in question: The output told the story The results were unambiguous. Three sessions. One blocker. Two victims. Blocking Blocked Wait type ...
We recently discovered a bug in one of our legacy ASP.NET MVC applications — the kind that doesn't throw an exception, doesn't log a warning, and doesn't announce itself in any way. It simply silently drops a filter on the floor. Unfortunately, that filter happened to be a security control. Here's the story of what happened, why it happens, and what we're doing about it. Remark: If you don’t have any legacy .NET Full Framework ASP.NET MVC apps remaining (good for you), you can stop reading. What we were trying to do Our application uses action filters for authorization. We had a global filter registered for all controllers that enforced a baseline set of access rules. For certain controllers, we wanted a stricter policy, so we added a local filter attribute directly on those controllers. Both filters shared the same attribute type. The attribute was decorated like this: The intention was clear: the local, more restrictive filter on the controller would...