Pointing in-flight work that ended up being unnecessary and adding no value

The proper protocol is to forget about being a story point accountant, and to honor the commitments associated with each Scrum artifact as opposed to committing to tickets.

Bear in mind that velocity is the rate at which work is Done, and not partly Done. Developers may use this measure to estimate how much work they can take on to meet a Sprint Goal by crafting a Done increment.

I don't think there is "proper protocol". There's no one-size-fits-all answer or approach to this problem, but I'm sure you can get plenty of really good opinions or perspectives on how this went down.

It seems to me like story points mean something to your organization. I don't understand what an "interrupt ticket" is, what value creating one would add, or why one would be assigned points. Story points are only useful to the team at the point of refinement and planning, as one potential tool for helping the team think about the amount of work they have done in the past versus forecast capacity and amount of work. Once a Sprint has been planned, there's not much value in playing accounting games with points.

If it was determined that work was no longer needed, my recommendation would just be to close the representation of that work as "won't do" or delete the item or throw away the card, depending on the tools and the team's need for record keeping. If any work has been started, that can also be discarded.

For me, the biggest concern would be around why this work was started in the first place. I'd want to understand why it remained in the Product Backlog if it was no longer necessary. It may be a good idea to look at the rest of the Product Backlog and make sure everything else represents work that is valuable and desired by stakeholders, closing out or removing anything that is no longer necessary or relevant. Problems should be fixed at the root cause, and getting to problems in backlog management would get you much closer to the actual root cause.

I'm going to echo @Ian and @Thomas.  

Points are estimates made based upon information known at the time the estimate is made.  Once work begins, you will undoubtedly discover new information that will on many occasions invalidate the original estimate.  Using estimates to determine whether a team is delivering is a mistake, in my opinion. I prefer to use metrics like throughput or cycle time.  Story Points are useful for a team to estimate if they feel they can complete work during a specified period of time.  

Is there any issue with how we handled the tracking of the story points?

Should we have handled it differently? Not tracked the story points at all? Or....? 

Just curious what the proper protocol would be in this case.

You are asking those questions of the wrong people.  The only ones that can answer them are people within your own organization.  There is no such thing as a "correct way to use and track Story Points" because there is no methodology or process I have ever encountered that require them to be used.  The current Scrum Guide has no mention of User Stories or Story points. It references Product Backlog Items and doesn't have a single use of any variation of the estimate. 

The problem is: the team completed the work (thankfully didn't merge anything). So there was wasted effort.

However, there is mention in the Scrum Guide of managing your Product Backlog and ensuring that it contains all of the work needed for a Product.  That management is an ongoing activity.  Items that provide no value to the Product should not exist in the Product Backlog.  The fact that this item existed and that it was worked on without determining the value it provided is something that your Scrum Team should discuss.  You need to determine why it still existed in the Product Backlog, why no one questioned the value provided by the ticket, and how to prevent anything like this from happening in the future. As Scrum Master one of your responsibility to the Scrum Team is helping them focus on the high value work. One of your responsibility to the Product Owner is to help understand how to effectively manage the Product Backlog.  

I suggest that you stop worrying so much about how to manage and report Story Points. Instead focus on helping the team and organization understand if value is represented by your Product Backlog items and if value is being delivered in each Sprint.

I agree with Daniel, Ian and Thomas, The same story can be cancelled, there is no need for interrupt ticket.

This case is retrospective candidate for whole scrum team -

1. SM to help PO to identify and maintain prioritized PB with highest priority items in place

2. PO to work with stakeholders to identify most important items needed by business in near future.

3. Scrum team to get involved with PO and identify the ways everyone can work on focusing on most prioritized item, developers work on ways to improve ways to refrains similar kind of bugs in future