How to handle a backlog item where the estimation is extemely off at the end (expect weeks, done in 30 min)

Context 

In my teams, we've been using Planning Poker for over a year now, and it's worked well for what we want to achieve. We use the standard (1, 2, 3, 5, 8, 13...) to estimate each work item before the sprint starts. We  have establish a previous sprints average velocity that we use (for example, 39 points). We then use that average, along with contextual factors (e.g., “John is on vacation this sprint, so let’s aim lower than 39”), to guide what (how many pts) we include in the new sprint initially..

So far, so good. Estimation errors happen occasionally, but they tend to balance out over time ( a  8 might be completed faster, a 3 might take longer. Overall, it averages out enough for our need.)

However, we recently estimated a work item at 8 points (we don’t directly link points to time, but for the sake of argument, let’s say it was perceived as a big week of work, more that one person, etc.). This time, the high estimate was due to uncertainty and the need for research.

But once we started working on it  — boom! A solution was found and applied quickly. Total time: under one hour.

Now, someone on the team rightly pointed out that leaving this item at 8 points will impact our velocity average for several sprints. On the other hand, retroactively adjusting estimates opens a can of worms.

So here’s the question: What’s a good way to handle this kind of situation?  Any suggestions?

I am tempted to « tought it » like that and point out at the next 3-4 sprints that the velocity is slightly high vs reality, since velocity is just a tool...