How to Sequence Spikes
So, how long should a developer spend on that investigation?
If the team can't estimate a user story—more canonically, a Product Backlog Item (PBI) in Scrum—with "close enough" accuracy within about 5 minutes during Sprint Planning or Backlog Refinement, the story either needs to be decomposed or replaced with a story spike.
If members of the Development Team need to go off and do discovery for a spike, you estimate the time and effort needed for the spike (usually less than two days, but I've seen Sprint-length story spikes in my professiona practice) and ensure that the spike is prioritized for the upcoming Sprint. Also make sure its estimate is part of the team's capacity planning for that Sprint.
Once the spike is completed, you would use what you've learned from the spike to decompose or estimate the story itself for acceptance into a future Sprint. As a general rule of thumb, it's unwise to have a spike and its dependent story within the same Sprint. There are exceptions for narrowly-scoped spikes, but don't put your Sprint Goal at risk by taking on work of unknown size or scope!
A Note on Spike Length
As mentioned above, an ideal spike is about the average size of a user story. In a typical two-week Sprint, the ideal time box for a spike is about one-half to two days in length. However, the spike should be as big as needed, but must never exceed the length of a single Sprint.
The point of a spike is to perform scoped learning. However, the scope should be just enough to make the stories or epics its related to estimable. Anything more than that, such as in-depth research or a product bake-off, really ought to be a set of PBIs in their own right.
Also, remember that story spikes aren't "free." They consume team capacity, and need to be tracked as work on the Product Backlog when they are known ahead of time, or created as extremely short time boxes on the Sprint Backlog if the need for a spike is uncovered for work-in-progress on a PBI within the current Sprint.