test(automation): end-to-end coverage for the #1928 object-schema resolver wiring#3208
Merged
Merged
Conversation
…olver wiring Adds a kernel-level integration test that boots LiteKernel with a fake objectql service (registry.getObject) + AutomationServicePlugin and proves the plugin bridges the engine's object-schema resolver to the live registry at start(): - the wired resolver returns the object's fields + types; - a flow registered through the running kernel doing arithmetic on a text field emits the tier-4 advisory (captured via process.stdout); - a sound condition stays quiet. Locks in the production integration point that #3190's engine-level unit tests (resolver set by hand) could not exercise. Test-only; no behavior change. Tests: service-automation 319 (+3 e2e); full suite green. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Hnji7EEYR2mGt6pY53a8Bm
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
📓 Docs Drift CheckThis PR changes 1 package(s): 6 hand-written doc(s) reference the affected code and may need an implementation-accuracy re-verification:
|
os-zhuang
marked this pull request as ready for review
July 18, 2026 12:35
This was referenced Jul 18, 2026
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.
What
Closes the last coverage gap from the #1928 series. #3190 added
AutomationEngine.setObjectSchemaResolverand wired it inAutomationServicePlugin.start()toobjectql.registry.getObject, but the engine-level tests set the resolver by hand — so the plugin's actual production wiring was never exercised end-to-end. This test does.The test
Boots a real
LiteKernelwith a minimal fakeobjectqlplugin (exposingregistry.getObject) + theAutomationServicePlugin, then asserts:objectSchemaResolveris a function that returns the object'sfields+fieldTypesresolved from the registry, andundefinedfor an unknown object.engine.registerFlow(...)whose condition does arithmetic on atextfield (title * 2 > 10) emits the tier-4type mismatchwarning (captured fromprocess.stdout) — and does not throw.stage == "won" && amount > 1000produces no schema advisory.Relies on the kernel's real bootstrap ordering (all
init()before anystart()), so the fakeobjectqlservice is present exactly when automation'sstart()bridges the resolver — the same sequence production uses.Testing
@objectstack/service-automation— 319 green (+3 e2e); full suite unaffected.patchfor the coverage).Refs: #1928 (closed), #3190.
🤖 Generated with Claude Code
https://claude.ai/code/session_01Hnji7EEYR2mGt6pY53a8Bm
Generated by Claude Code