First the obvious:
Is the desired SPI1 interrupt enabled in NVIC?
Are the desired SPI interrupts unmasked in the SPI peripheral?
Have you verified this with a debugger?
Which SPI interrupt(s) have you enabled, and are you certain their conditions are being met?
You're sure your handler has the correct 'magic' name? Not sure about CubeMX but often if the name is wrong, it will just compile it as a normal function and you get no warning that the linker has stubbed out the ISR. Remember that C is case sensitive.
The less obvious:
What are you actually doing in EXTI7, and what is triggering it? If it 'initiates the SPI xfer', is it possible it is clearing the enabled interrupt flags in the SPI peripheral e.g. by adding data to the FIFO? By default EXTI has higher priority than SPI1 and will be serviced first. If it's running frequently / has a long run time, or even worse, if its timing gets synchronized with the SPI peripheral, it's could be very likely it will be running when the SPI interrupt fires. If its behaviour clears the SPI interrupt flags, then I believe the pending SPI interrupt doesn't get serviced (or any flag checks you do in the ISR may fail unexpectedly).
As to how to approach this, I would disable EXTI7 and do something in main() with the SPI peripheral that you think should trigger the interrupt. If it's not getting triggered, get out the debugger and interrogate the SPI registers and interrupt flags as the transfer gets executed, probably you've misconfigured the peripheral.