It's actually something a little different. To manage the wallet in a way that reduces the number of inputs (and therefore weight and cost) of each transaction we always spend the change of the previous transaction. That means if the previous transaction hasn't confirmed yet we're spending an unconfirmed input. If fees suddenly spike that can cause a long chain of unconfirmed transactions and very occasionally it hits the limit of the length of that chain so although we have prepared and signed it we can't broadcast it until the queue clears out.

There's nothing that can be done about it other than waiting for the mempool to clear out a bit.