Obsolete user story

Scrum is mechanism of discovering and minimizing risks and removing easte, not the tool to push production.

In this case Scrum already successfully achieving the task of  identifying the problem in the operations, which is a success, not a failure.

The task which is obsolete is obsolete. Is gone for good. 

The team does not commit to work in the Sprint Backlog. The team commits to the Sprint Goal.

When you're dealing with the unknowns and uncertainties of complexity, you are likely to find that some work you thought you needed to do is unnecessary, just as you are likely to find that you need to do something you didn't plan on doing. This should not be considered unusual or unexpected. How you indicate this depends on your context, though, and what kind of information you need. Some teams want to keep track of this work and learn from it, since time and effort was invested to get it ready for a Sprint and select it at Sprint Planning, but other teams can simply discard the work and move on. It's up to the information needs of the stakeholders and, perhaps, the tools that you are using to manage the work.

What would you do as SM when the Delivery team identifies an obsolete user story in the middle of a 2-week Sprint. 
Team had committed to a story in Sprint Backlog and they are mostly innovating

I don't think they are. If they were innovating, they would not have committed to such a thing. They'd have recognized that a user story is a placeholder for a conversation about a potential requirement. When brought together in a Sprint Backlog, with a Sprint Goal commitment worth aiming for, these conversations are a coherent forecast of the discussions then needed to innovate.

As a Scrum Master, I wouldn't do anything with the item specifically.  The Sprint Backlog is made and owned by the Developers.  They should decide what to do with that item just as they do with any item that they feel is still viable. I would suggest that conversations occur with the Product Owner to help them understand how and why it is obsolete.  And I would also bring up the item in the Sprint Retrospective to see if there is anything the team can learn about the situation.  

The Scrum Guide states this in the section that describes the Sprint Backlog. 

The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum.

It is expected that the Sprint Backlog will change during the Sprint to support the Sprint Goal as more information is discovered.  Items may be added, some removed, some modified.  That is normal in a situation where information is never fully known before the work begins. 

A user story is only a requirement; what would be the value of the team spending time and money developing a requirement that does not offer value?  What can the team learn from both, not needing to develop the unnecessary requirement (perhaps product knowledge), and the process of how this story got into the Sprint (perhaps improved refinement).  The question, (1) If the item is removed from the Sprint, when would the team discuss and how would the team learn how the item got there in the first place? :)

At the time the decision is made to remove it from the Sprint.  Why postpone the learning?  At the very latest, it could be discussed at the Sprint Retrospective.  In my experience, the sooner you discuss the situation, the more that is known and the better the learning. 

Empiricism is embedded deep into Scrum.  It is not just something you do at the end of the Sprint.  It is something you do continuously.  You do something, as new information is uncovered, you inspect the previous decision and adapt if necessary.