AI image generation queue not purging declined slaves while browsing slave market

Expected Behavior

While viewing slaves in any of the markets (I don't think it's specific to the market, rather, the market is an ideal situation for this scenario to happen), the AI generation queue should remove pending requests for slaves that I have declined, such that the slave currently being displayed begins generating immediately.

Current Behavior

When repeatedly pressing "Decline to purchase and check out another slave" the queue gets backlogged and sometimes will eventually give up on the currently displayed slave.

Steps to Reproduce

1. Create a new game or resume an existing one
2. Enable AI art, run A1111 web ui client
3. Go to buy slaves, any market
4. Repeatedly press "Decline to purchase" and observe the A1111 console continue to work on old requests instead of purging them

Additional information

• Release ID: master branch, after 4.0.0-alpha.27
• Commit: Latest commit as of posting cfbd6015, however I have consistently observed this problem for over a month--pretty much ever since the image queue was implemented.
• Save file: I can provide one if necessary but this problem has occurred with every game I play, not specific to a save.

I'm running an RTX 4070Ti and each image takes about 5 seconds to generate with my settings. When the queue gets backlogged with declined slaves it can take over a minute for it to work through all of them and sometimes gives up before reaching the current slave. It's odd because this MR !11496 (merged) looks like it should prevent this.

Here is a pastebin dump of the A1111 console logs https://pastebin.com/sPDC94H0

EDIT: Checked the browser console while waiting for the queue to catch up. Curious behavior:

Stable Diffusion fetch interrupted
Fetching image for slave 271, satisfying 1 requests
Fetching image for slave 271, satisfying 1 requests
Fetching image for slave 271, satisfying 1 requests
Fetching image for slave 271, satisfying 1 requests
Fetching image for slave 271, satisfying 1 requests
Fetching image for slave 271, satisfying 1 requests
Fetching image for slave 271, satisfying 1 requests

Looks like the while loop in the process function in stableDiffusion.js iterates multiple times. The body and slaveID for each fetch corresponds to a previously declined slave that for some reason still appears to be in the queue...except the queue object itself does appear to have been cleared with the interrupt so... not really sure what's going on.

changed the description

changed title from AI image generation queue gets back logged while browsing slave market to AI image generation queue not purging declined slaves while browsing slave market

changed the description

changed the description

changed the description

It feels like an infinite loop to me. If I decline several slaves in a row, then go on to buy one, then browse several screens setting up her rules and outfit and such... I get this

Not sure what's wrong, but if declined slaves could be cancelled that would be ideal.

Later I get this. I think this error is the error the ai is sending to the ai console when it tries to give the image to freecities but since it's a declined slave or some such, or I've browsed away from the page, the image is rejected in response to being sent from the ai to the game.

I browsed like 6 or 7 slaves yet it's generated dozens of images. Hence my guess it's an infinite loop, but maybe the loop isn't infinite and merely resets the entire queue every time I open a new page of the game... Meaning that the 6or7 slaves have lead to a queue of 40 or 50?

I managed to use nvidia's new rttensor engine profile speed boost to get this lavish number of iterations down to lightning fast even on my 4070ti, but well, I am not sure I can wait even this few seconds if I have to never browse away from the page.

Now a minute or two later I've gotten a delivered image for the current slave and current page I am looking at, yet the queue is still full

So it's not just that declined slaves aren't removed from the queue when I decline them. It appears they may NEVER be removed from the queue, being regenerated infinitely?

One good solution to this I think would be to take the "interrupt button" from automatic1111webgui and add it somewhere to freecities. If I could just click an interrupt button to cancel this infinite loop that would alleviate the problem.

I could force close the console mid-process and restart it with the .bat file....but.... I've found that this can lead to some sort of error/corruption in the new nvidia rttensor extension/speedboost engine profile system. Forcing me to spend 10-15minutes regenerating them.

I even went to the webgui and started an image generation task, so that the interrupt button would appear and I could click it. The image generation from the webgui started shortly later, and it interrupted on command shortly after that. That then several images later ended the infinite loop from freecities. Which proved the effectiveness of whatever that "interrupt" button is doing.

TLDR: This problem is so severe, that I do not think solving it is sufficient. This sort of infinite loop bug could reappear at any point in time. But it would be solved forever if freecities had a button somewhere inside of it that would function like the webgui's interrupt button.

FC sends that exact interrupt command to Automatic1111 every time you change pages; it should do precisely what that button does according to the documentation. As far as I can tell, it just doesn't work sometimes, and instead decides to regenerate that image repeatedly.

@svornost For some reason the while loop continues resolving previous requests. I added a console log after the await fetch and before the item resolve, and the items actually being resolved are previous requests, in the order that they were pushed onto the queue. Why this is happening I haven't been able to figure out yet.

For example:

Fetching image for slave 271, satisfying 1 requests
resolving item for slave 255
Fetching image for slave 271, satisfying 1 requests
resolving item for slave 256
Fetching image for slave 271, satisfying 1 requests
resolving item for slave 257
Fetching image for slave 271, satisfying 1 requests
resolving item for slave 258

It's odd because I verified that the queue length is 1 every time the loop iterates. Those previous items do not appear to be in the queue, and yet they continue to be resolved. There is some weird disconnect going on around the fetch that I can't quite figure out. It is preparing the correct request, and the fetch itself contains the correct data for the current item, but then the item it ends up resolving is a previous one... weird.

This issue appears to have been resolved by !11594 (merged)

closed