Previously, stream tags would be lost (not propagated downstream) when a block has a tag delay set and it is called with a number of input samples that is less than the delay. Since this happens depending on the scheduler and the number of samples provided, tags might mostly work or seemingly randomly disappear. The problem occurs because a wrong correction is included for underflows in unsigned arithmetic that limits the tags propagated to a smaller sample window than desired. Correctly detecting the underflow and setting the value to 0 rather than abs_start or abs_end fixes the problem. For a real example, let the d_attr_delay=209, abs_start=0, and abs_end=200 with a tag at input sample 0. Then tags from min(abs_start, abs_start - d_attr_delay) == 0 to min(abs_end, abs_end - d_attr_delay) == 200 are iterated through, including the tag at 0 (item_time == 209), but it is not propagated to the output yet since item_time >= abs_end (209 >= 200). On the next call to the block, with abs_start=200 and abs_end=400, the tag at input sample 0 is ignored because min(abs_start, abs_start - d_attr_delay) == 200 and the iterator skips it. The correct calculation for the lower bound of the tag iterator would result in 0 and find the tag since (abs_start - d_attr_delay) == -9 -> 0 when constrained to unsigned values. With the proper lower bound (and upper bound corrected as well), the tag at 0 is found with an item_time == 209 which falls between abs_start and abs_end and is propagated to output sample 209.