Sprint Review...

PO shall be best person to decide the priority and impact of these last minute bugs. He shall put together same and make a decision on business needs.
If the bugs are minor, that story can be accepted provided it is been communicated to stakeholders by PO in review.

any work that is compliant with the definition of "done" is demonstrated during the sprint review. As long as Pdo (work accepting) and dev team (work creating) sharing the same understanding on definition of "done" then none of them will either accept or demonstrate the work in sprint review.

All work, whether done or undone, should be inspected in a Sprint Review. Work that was planned into the Sprint but which remains undone should be re-estimated and returned to the Product Backlog. it can then be planned into a future sprint.

All work that remains on the Product Backlog should also be reviewed, regardless of whether or not it was inducted into the current Sprint. This is an opportunity to prepare the Product Backlog for the next Sprint Planning session.

An interesting topic. When you re-estimate the work, you will probably "lose" some estimated size which will not appear in the velocity, so your planning might be less accurate. How would you deal with that? Would you advise the team to decompose the work further in the refinement and planning sessions to get a more accurate velocity? The usual answer is that it is not possible to decompose it further. Is it allowed to add the "missed" size to the velocity of the previous sprint?
I know Scrum is about delivering value and not velocity, but still I am interested in an accurate measurement for planning purposes.

> Is it allowed to add the "missed" size to the velocity of the previous sprint?
> I know Scrum is about delivering value and not velocity, but still I am interested
> in an accurate measurement for planning purposes.

Bear in mind that when an item is re-estimated the total size of the Product Backlog is reduced. That is effectively how the work done is recorded. For planning purposes you will see less work remaining in the backlog. The recorded velocity is immaterial.

The recorded velocity is immaterial.

Then why do people record it? In my opinion there are two reasons:
1. In Sprint Planning, the team can better estimate how many PBIs they can pull into a sprint
2. After a retrospective where they decide about a strategy to improve productivity, they can take a measurement to see if it worked.
Now you will say, productivity is not USP/time (velocity) but it is value/time. OK, but how do you measure value? And how you distinguish the change in productivity caused by the Retrospective from the change caused by the PO's decisions in sorting the PBIs?

>> The recorded velocity is immaterial. 
> Then why do people record it?

In Kanban and similar approaches, velocity is a useful primary measure, as are throughput and cycle time. There is no Product Backlog that can be inspected for burndown.

In Scrum, teams often do use velocity as you say. However it is less than ideal as a forecasting tool because - when recorded properly - velocity excludes any partial credit for undone work.

A better planning measure in Scrum is to consider the work inducted into the Sprint minus any work re-estimated and returned to the Product Backlog. An even better one is to look at a planned Sprint Backlog in its entirety, and to view individual PBI estimates as nothing more than a very rough guide to the whole. Scrum after all is about the delivery of value as expressed through Sprint Goals, and not about being story point accountants.