If what you want is that each pulse length be calculated using the most recent data available, why not compute these about 1ms before the next pulse start? This can be done simply using output comare in another channel of the same timer. Then you will have 500µs for calculating the next pulse length and update the pulse length comparator value and you should have finished 500µs before the next update event (at the end of the period, just before the next pulse starts) having thus enough margin to be sure you will be OK.
However I’m afraid you may have to look at HAL timer code as I’m not sure there is standard APIs to do that. Perhaps a simple call to HAL_TIM_OC_Start_IT with another channel of the same timer will be enough, after having set the corresponding CCxR register to 4/5 of the timer period... (the same register you set to set the pulse length); then HAL_TIM_OC_DelayElapsedCallback should be called about 1ms before the next pulse start, so you had plenty of time to calculate its length...However, while looking at the code, although the IRQ handler knows what channel has generated the interrupt, it does not pass this information to th eDelayElapsed callback (it even calls both the pulse terminated callback and the delay elapsed callback, as PWM is based on output compare...), so you must (in both callbacks) check if the channel that generate the IRQ is the one you are interested in, by
if(__HAL_TIM_GET_IT_SOURCE(htim, TIM_IT_CC1) !=RESET)
It’s a pity that, while there is 4 independent channels in a timer, the HAL layer does not support using more than 1 channel at the same time... We thus have to trick it to obtain what we need.