[BUG] Multiblocks will void outputs if the first recipe outputs more items than the output bus can handle

Describe the bug:
If a recipe is run in a multiblock and the recipe outputs more items than the output bus can accommodate, the multiblock will run voiding all outputs.

Versions:
Forge: 14.23.5.2855
GTCE: 1.15.0.721

Modpack: none

Addons: none

Playing Solo: yes
New world generated: yes

Steps To Reproduce:
Build a blast furnace with a ULV item output bus with power(any tier input bus will work). Place ruby dust into the item input bus and the multiblock will run voiding all outputs

Expected behavior:
The multiblock does not run until an item output bus large enough to accommodate the recipe is used instead.

Screenshots: NA

Additional context: if there are items in a larger output bus and there is no room for a recipes outputs, the multiblock will correctly not run until there is room.

This is currently intended behavior, seen by this section of code here:

GregTech/src/main/java/gregtech/api/recipes/Recipe.java

Lines 255 to 263 in f9d7017

    
           public List<ItemStack> getAllItemOutputs(int maxOutputSlots) { 
        
               List<ItemStack> outputs = new ArrayList<>(); 
        
               outputs.addAll(GTUtility.copyStackList(getOutputs())); 
        
               outputs.addAll(getChancedOutputs().stream().map(ChanceEntry::getItemStack).collect(Collectors.toList())); 
        
               if (outputs.size() > maxOutputSlots) { 
        
                   outputs = outputs.subList(0, maxOutputSlots); 
        
               } 
        
               return outputs; 
        
           }

However some discussion has come up in #1337 and #1215 if this behavior should be changed or not.

Personally, I think changing it would be a pretty big behavior change, although it might be worthwhile to do.

There is different but related issue I found a while ago.
I tried to implement a "wooden item bus" that only holds 1 item for early game use with MultiblockTweaker.

Although it is easy to implement, it doesn't work because optimisations within the bus handling code assume all slots are 64 items in size. I think there are other assumptions in that code about how the buses are implemented?

it doesn't work because optimisations within the bus handling code assume all slots are 64 items in size

As I recall, the assumption made is that each slot in the inventory permits an ItemStack whose size() is anywhere from 1 to the Item's defined maximum stack size, be that 1, 16, 64, etc. So yes, your case does not generally comport with that assumption.

	public List<ItemStack> getAllItemOutputs(int maxOutputSlots) {
	List<ItemStack> outputs = new ArrayList<>();
	outputs.addAll(GTUtility.copyStackList(getOutputs()));
	outputs.addAll(getChancedOutputs().stream().map(ChanceEntry::getItemStack).collect(Collectors.toList()));
	if (outputs.size() > maxOutputSlots) {
	outputs = outputs.subList(0, maxOutputSlots);
	}
	return outputs;
	}