When using bitbake-getvar for scripting, I have two consecutive calls to get two different variable contents. The output should be stored in a variable, thus, the commands should only emit the value of the queried variable:

  YOCTO_BUILD=$(bitbake-getvar -r busybox --value B -q)
  YOCTO_SOURCE=$(bitbake-getvar -r busybox --value S -q)

While the first call only prints the variable value to stdout, the second call prints:

  NOTE: Reconnecting to bitbake server...
  NOTE: Retrying server connection (#1)... (09:07:49.112555)
  /path/to/tmp/work/../build

which will break the script's variable.

I've noted this only happens when the bitbake from the previous call is still terminating (seems to work fine for still running/memres bitbake).

Digging through the code, I realized this is a somewhat intentional behavior for bitbake that ensures no log messages get lost. It happens in the print_ui_queue() method, registered as an exit handler, which drains all remaining UI LogEvents (if no UI is present) and dumps them using simple stdout/stderr log handlers.

My understanding is that the terminating bitbake still receives and prints these logs before finally exiting.

What's unclear to me is if this can be avoided for the bitbake-getvar use case.
An option I have thought about is to ensure the previous bitbake is fully shut down before spawning a new one. But maybe there are also options for silencing the log draining? Or something conceptual I haven't thought of?