That does not make any sense to me. If we have to wait for the update so we can have the output from the script and from the async save routine in the same place, the entire advantage of async saving is gone\!

Oh. The following idea feasible?

Suppose a situation:
\# max\_queue\_size = 10
...
\# The current waiting put queue is 9
Getting 60 pages from wikipedia:en...
\# Add 10+ pages to the put queue at same time
\# The current waiting put queue is 19+

Post-processing \[\[en:xxx\]\]

"Updating links on page \[\[en:xxx\]\]." 10+
...
"Updating page \[\[en:xxx\]\] via API" 10+
"Getting 60 pages from wikipedia:de..."
......

What you want is not really clear to me, but I suppose you want to let the bot stall when there are 10 pages waiting to be saved?

What would be the use case for that?

I mean is all associated pages of a page as a unit to output and updates, rather than each page as a unit.

Is this a enhancement for core or compat?

@Mpaa Could this be fixed in a similar way as T135992? Or is this even solved with T135992?

Honestly the wanted behavior is not clear to me.

As I understand this, this is a request to have synchronous log in asynchronous mode. The request to have 3 main threads: a read thread, a write thread, and a log thread. The log thread would group incoming log messsages by page and output them to the log file when a certain final message (post-processing-for-page-is-done hook or something?) is thrown finally.

There is another similar request in T73646: That suggests there should be another - the 4th? - thread: read thread, write thread, log thread and an output thread. The output thread would group incoming messages (save-success or -fail messages, API warnings or similar) and output them only if pywikibot.input() or similar is currently not being called (not waiting for the user interaction).

At least this is how I understand these two tasks.

But maybe I got it wrong. This task may be to some particular script as the attached log file from the sourceforge bug report page could suggest: