feat(engine): make Runtime init lazy for read-only Code/Tooling (#269) - #281
Open
AntoineToussaint wants to merge 1 commit into
Open
Conversation
…ling (#269) Read-only Code/Tooling calls (ExecuteCode, GetSemanticIndex) previously acquired an AgentSession that unconditionally ran Runtime Load/Init, coupling project inspection to toolchain/environment readiness and blocking semantic recovery on malformed projects. Move runtime Load/Init out of AgentSupervisor.acquire into a lazy, mutex-guarded ensureRuntime (mirroring initializeBuilder). Only Build/Test/Lint/ Stop initialize the runtime, on first use. Failures stay wrapped as *agentInitializationError so Test keeps returning the typed env-blocked response. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #269.
Summary
ExecuteCode,GetSemanticIndex) now start the production agent without running the Runtime lifecycle. RuntimeLoad/Initmoved out ofAgentSupervisor.acquireinto a lazy, mutex-guardedensureRuntime, mirroring the existinginitializeBuilderpattern. OnlyBuild/Test/Lint/Stopinitialize the runtime, on first use.*agentInitializationError, soService.Testkeeps returning the existing typedenv-blocked (runtime-initialization)response.Behavior verified
A new real-agent test (
pkg/engine) drives the production python agent against malformed source:GetProjectInforecovers the module/language andGetSemanticIndexreturns aDEGRADEDindex with aparse_failedissue — both with the runtime never initialized (runtimeOK == false). The firstTestthen initializes the runtime lazily (runtimeOK == true).Known coordination (mind#369)
The generic agent (
0.0.21, used for jvm/dotnet) still binds its Code source directory duringRuntime.Load; without it, its code server only sees the ephemeralservice.codefly.yamland reportslanguage "unknown". Moving that binding to agent startup — the way the python agent already works — is codefly-dev/mind#369. Until a decoupled generic agent is published andsourceworkspace.GenericPluginVersionis bumped past0.0.21,TestGatewayInspectsJVMAndDotNetCodeUnitsThroughGenericAgentis skipped. The skip is gated on that version constant, so bumping the pin re-enables the proof automatically.Test plan
go test ./pkg/engine/(incl. new malformed-source decoupling proof)go test ./pkg/gateway/(python/node runtime proof still green; jvm/dotnet inspection gated on generic-agent bump)go test ./pkg/control/ ./pkg/mcp/go build ./...,go vet ./pkg/engine/ ./pkg/gateway/go test ./...🤖 Generated with Claude Code