Before we were blocking a bunch of server responses here, which then would hold up the client-side? But this would be fine because each status update would just block and get uploaded eventually?

Now the plugin will be more eager to drop status updates if the server-side is slow to respond?

Correct, the idea was to keep the behavior consistent to how the bundle status updates now work. This change isn't required to support timeouts so I could reverse it until someone asks for it, but it seems like it could cause problems?

I decided to reverse the change to update discoCh and decisionLogsCh to buffered channels. Seeing it isn't required to resolve the graceful shutdown issue, probably better to leave it be until it can actually be proven to be a problem.

Depending on the status of loop() could this - and below - turn into a blocking read if loop() manages to squeeze in a read between if len(p.pluginStatusCh) != 0 and here? Or are we confident this won't happen?

Should these be individual select blocks? E.g.

select {
case status <- p.pluginStatusCh:
   p.lastPluginStatuses = status
   changed = true
default:
}

select {
case status <- p.bulkBundleCh:
   p.lastBundleStatuses = status
   changed = true
default:
}

etc ...

Good idea! Updated to use select instead to avoid any possibility of blocking.

Would it be possible to add a test for when the plugin needs to abort/drop an update. E.g. if the server doesn't respond in a timely manner?

I added a test TestSlowServer, starts a server that blocks and gives time to update the bundle status twice and checking if the first status is dropped.