It looks like macOS runner is failing due to race as I feared. I can't think of a good way to enforce that this fix is hit without internal testing. Essentially I'd want to either mock the client or the API to block requests to client.CreateWorkspaceBuild or POST to /api/v2/workspaces/%s/builds until all commands are synced in execution.

We could also just remove the count assertion but then we have no way to know that we're actually hitting the edge case.

Got any better ideas @johnstcn @mtojek ?

Got any better ideas @johnstcn @mtojek ?

github.com/coder/quartz? 😅

That, or dbmock could let you do something like

dbmock.EXPECT().InsertWorkspaceBuild(gomock.Any(), gomock.Any().Do(func() {
<-waitForCommand
}).AndReturn(...)

Got any better ideas @johnstcn @mtojek ?

github.com/coder/quartz? 😅

That, or dbmock could let you do something like

dbmock.EXPECT().InsertWorkspaceBuild(gomock.Any(), gomock.Any().Do(func() {
<-waitForCommand
}).AndReturn(...)

Thanks for the suggestions. Quartz is a bit too distant / side-effecty to properly do this I think 😅. I'll look into dbmock but that only works if it actually passes the invocation to a real DB. Don't want to mock all DB calls required to do this E2E so might be easiest via some kind of middleware used in tests where you can intercept any request before passing it on to the next handler.

might be easiest via some kind of middleware used in tests where you can intercept any
request before passing it on to the next handler.

That's actually pretty nice! It seems like it should be simple enough to allow wrapping coderAPI.RootHandler with a middleware in coderdtest.NewWithAPI.