Spanning-Tree Protocol is a link management protocol that provides path redundancy while preventing undesirable loops in the network. For an Ethernet network to function properly, only one active path can exist between two stations.
Multiple active paths between stations cause loops in the network. If a loop exists in the network topology, the potential exists for duplication of messages. When loops occur, some switches see stations appear on both sides of the switch. This condition confuses the forwarding algorithm and allows duplicate frames to be forwarded.
To provide path redundancy, Spanning-Tree Protocol defines a tree that spans all switches in an extended network. Spanning-Tree Protocol forces certain redundant data paths into a standby (blocked) state. If one network segment in the Spanning-Tree Protocol becomes unreachable, or if Spanning-Tree Protocol costs change, the spanning-tree algorithm reconfigures the spanning-tree topology and reestablishes the link by activating the standby path.
Spanning-Tree Protocol operation is transparent to end stations, which are unaware whether they are connected to a single LAN segment or a switched LAN of multiple segments.
The whole idea behind spanning tree is that you can have a link fail, because you have a pair of bridges connected via two paths. Spanning tree will leave a port blocked until it is needed. Then we should be able to unplug redundant links and connect new ones without interruptions? Sorry, but no, it doesn't work that way.
When the physical media comes "up" the newly connected bridge will send the reconfiguration BPDU, and the other connected device will comply. All traffic is stopped for roughly 50 seconds while a spanning tree calculation takes place. It's wonderful in practice, since you are limited to a short downtime compared to a permanent downtime if a switch explodes and you lack redundant paths, but the 50-second penalty is very sub-optimal.