feat: send build events over grpc and new lsp cmd #3953
Conversation
wesbillman
force-pushed
the
build-engine-grpc-events
branch
from
6af259c to
c898162
Compare
wesbillman
force-pushed
the
build-engine-grpc-events
branch
from
c898162 to
a91b5ad
Compare
| } | ||
|
|
||
| func (u *updatesService) StreamEngineEvents(ctx context.Context, req *connect.Request[buildenginepb.StreamEngineEventsRequest], stream *connect.ServerStream[buildenginepb.StreamEngineEventsResponse]) error { | ||
| events := make(chan *buildenginepb.EngineEvent, 64) |
There was a problem hiding this comment.
I wonder about this case:
- Start
ftl devin a terminal - Build engine fails to build a module, has code errors
- IDE launches, connects to build engine for updates
- IDE thinks everything is all good, rather than receiving the initial state
There was a problem hiding this comment.
Yeah this will def happen. And actually did happen before as well. :)
We might want to think about the lsp itself being about to trigger a build when it activates to get the current errors. I'm guessing other extensions might do something similar to get their initial state 🤔
internal/buildengine/updates.go
Outdated
| } | ||
|
|
||
| if berr.Type == builderrors.COMPILER { | ||
| continue |
There was a problem hiding this comment.
Should this be done buildengine side or LSP side? It feels LSP specific to me
There was a problem hiding this comment.
You're totally right! I will remove this so that we can report all the errors 🤦
|
|
||
| // Associate by filename. | ||
| for _, e := range buildErrors { | ||
| if e.Type == builderrors.COMPILER { |
There was a problem hiding this comment.
ah it is filtering on LSP side anyway
| default: | ||
| logger.Debugf("Connecting to build updates service") | ||
| if err := l.streamBuildEvents(ctx, client); err != nil { | ||
| logger.Debugf("Failed to connect to build updates service: %v", err) |
There was a problem hiding this comment.
Similar logic to the comment about initial state in the stream, theres bad states that could arise here:
eg: errors were present in buildengine, lost connection / build engine dies, when we reconnect those errors may not be present anymore but the LSP wont be notified. Maybe we need to reset lsp state here.
Fixes #3925
This decoupling allows us to run the LSP independent of
ftl dev. This means that our extensions can just start and stop the lsp whenever they want and it will pick up language server updates.So now we can use VSCode with ftl without having it also start and stop the dev server.