feature: EE2-1557 http handler module#5
Merged
Conversation
Signed-off-by: Valery Piashchynski <piashchynski.valery@gmail.com>
wolfy-j
reviewed
Dec 12, 2024
wolfy-j
added a commit
that referenced
this pull request
Feb 23, 2026
wolfy-j
added a commit
that referenced
this pull request
Feb 23, 2026
wolfy-j
added a commit
that referenced
this pull request
Feb 23, 2026
wolfy-j
added a commit
that referenced
this pull request
Feb 23, 2026
wolfy-j
added a commit
that referenced
this pull request
Feb 23, 2026
wolfy-j
added a commit
that referenced
this pull request
Feb 23, 2026
wolfy-j
added a commit
that referenced
this pull request
Feb 23, 2026
wolfy-j
added a commit
that referenced
this pull request
Feb 23, 2026
wolfy-j
added a commit
that referenced
this pull request
Feb 23, 2026
wolfy-j
added a commit
that referenced
this pull request
Feb 23, 2026
wolfy-j
added a commit
that referenced
this pull request
Jul 4, 2026
- Keep api/net.ApplyOverlayPair as a deprecated thin wrapper over OverlayResolver so out-of-tree Go callers do not break (codex). - Network boot component fails loud (ErrFrameResolversMissing) instead of silently skipping registration when the registry is absent, so a wiring bug cannot degrade the overlay to clearnet (fable #1). - Remove the now-redundant SetMultiple(task.Context) from the wasm and lua Execute handlers: the function registry executor already applies task.Context to the same forked frame and is the sole caller (fable #3). - Drop the speculative FrameResolverOrderFSRoot constant and fs-root comment references; this PR migrates only the network overlay (fable #4). - Fix stale comments and the test section header (fable #5).
wolfy-j
added a commit
that referenced
this pull request
Jul 4, 2026
* refactor(runtime): generic frame-context resolver registry Frame-decorating options (the network overlay, and future ones like a filesystem root) were hand-wired into every dispatcher: the process manager and both the wasm and lua function lifecycles each called netapi.ApplyOverlayPair, leaking api/net into generic machinery and forcing every new option to touch every dispatcher. Introduce ctxapi.FrameResolvers: an ordered registry of (ctx, options) -> ([]Pair, error) resolvers, carried on the AppContext and populated once at boot. The two real choke points — the function registry executor (shared by lua and wasm) and the process manager Start — apply the whole set generically. Reads are lock-free (atomic snapshot, copy-on-write on register), mirroring the interceptor registry; the no-resolver path is ~1.4ns with zero allocations. Network migrates onto it: api/net.OverlayResolver replaces ApplyOverlayPair and is registered by the network boot component. The dispatchers no longer import api/net or api/fs; a new frame-context option is one resolver plus one Register line, with no dispatcher edits. * review: address codex + fable findings on frame resolvers - Keep api/net.ApplyOverlayPair as a deprecated thin wrapper over OverlayResolver so out-of-tree Go callers do not break (codex). - Network boot component fails loud (ErrFrameResolversMissing) instead of silently skipping registration when the registry is absent, so a wiring bug cannot degrade the overlay to clearnet (fable #1). - Remove the now-redundant SetMultiple(task.Context) from the wasm and lua Execute handlers: the function registry executor already applies task.Context to the same forked frame and is the sole caller (fable #3). - Drop the speculative FrameResolverOrderFSRoot constant and fs-root comment references; this PR migrates only the network overlay (fable #4). - Fix stale comments and the test section header (fable #5). * review: fail closed on missing frame resolver * review: harden frame resolver claims * test: isolate frame resolver claim tests
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
2 participants
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.
Reason for This PR
closes: https://jira.spiralscout.com/browse/EE2-1557
Description of Changes
API:
Tasknow contains two new methods (Contextwhich returns the current context andUpdateCtxwhich updates (or set) current context for theTask+ new field:context.)New carrier type: (
types.go):HttpContextCarrierNew context key for that:
HttpHandlerKeyIn the http layer,
HttpContextCarriershould be initialized with the http request + response write and populated into theTask's context viaUpdateCtxmethod.http_handlermodule contains a few basic methods:methodwhich returns current http method +writewhich writes some data. This PR does not support multiple writes (because in Go, after the first write, StatusOK header would be sent automatically), but needed data structures have been prepared and located in thehttp_wrapper.gofile (would be used via separate PR after API stabilization).