Repository navigation
feat(compat): support the upstream signal-processing entrypoint - #541
Merged
codelion merged 1 commit intoOct 23, 2026
Conversation
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
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.
The upstream signal-processing entrypoint omits model configuration, queries a diagnostic experiment before creating the experiment it actually runs, passes sampler/evaluator counts to the controller, and orders results by generic
score. These calls prevent it from using the existing local walkthrough.Extend
run_entrypoint.pyto execute its originalmain()with byte-identical staged sources. A signal-specific experiment subclass supplies the explicit--modelwithout mutating the upstream configuration. The runner requires the reviewed diagnostic-then-completed lifecycle, so caught setup failures and early returns cannot appear successful. During this main,SAVE_PROGRAM_DIRpoints to the stagedprograms/directory and is restored on success or failure, keeping optional evaluator archives away from inherited destinations.The isolated local facade adds a client-scoped, in-memory experiment lookup returning only name/state. Generic
scoreordering refers to the explicitly selected objective. Positivenum_samplers/num_evaluatorsarguments are accepted with a warning that they are ignored: synchronous execution has already finished, and the controller neither reruns evolution nor creates workers. Other cloud query/controller options remain unsupported. Existing seed-only defaults, explicit endpoint/key selection and best-only results are preserved.Validation:
main()at official revision34cd919193945c6dc81053f9af594031b54f41a8, each seed-only and with one scripted proposal through real OE workers. Original and staged Python source hashes remained unchanged, SDK imports were blocked, temporary aliases were cleaned up, and guarded socket/HTTP/credential-lookup attempts were zero.overall_score=0.49904861783269006withsuccess_rate=1.0in both runs; its original evaluator archive confirms the scripted candidate was evaluated. Both earlier examples also retained their reporting flows. Validation used Matplotlib 3.10.9 as documented by the existing walkthrough; no real model or managed-service requests were made.Continues #468 without closing it. This covers the three reviewed local entrypoints, not arbitrary SDK examples, cloud concurrency semantics or a full archive API. Signal-processing archive filenames can be reused by the upstream saver. Fixed proposals validate integration rather than optimization quality. Trusted code retains normal process privileges; no sandbox, strict cost cap or base dependency changes are introduced. Dedicated upstream-example CI, complete round-trip run coverage and actual managed-service validation remain follow-ups.