As you say yes I could just run that at regular intervals rather than in an interrupt
That's not what I meant. You use the interrupt to kick off the process but on finishing you just take a look to see if you've missed a new one. If so, deal with it otherwise back to waiting for the interrupt. So it's not a regular interval thing, just making sure you're really done at the end.
I don't know how the interrupts works on this, but my guess (which may be wrong!) is that receiving the message triggers the interrupt and it then stays active until you ack it. When you ack it, it won't trigger again until a new message comes in. In other words, the receipt of the message is the trigger, not the message being in the buffer (subtle difference). If that is the case then you should ack the interrupt as soon as you have the message details (index position, etc) and before spending time processing. Then when you exit the ISR it will just go back in and do it all again if a new message has come in whilst you've been processing, otherwise you're done.
The trade-off in that is the overhead of doing a return from interrupt and going back in again, vs doing a check in a loop. The loop would potentially halt everything if you did get data coming in too fast, whereas exiting the ISR would potentially allow a different ISR to sneak in and keep things going. (I really dislike having potentially endless loops in ISRs!)