feat(public-apps): share the start-process shape between public and direct modes - #730
Draft
Raina451 wants to merge 1 commit into
Draft
feat(public-apps): share the start-process shape between public and direct modes#730Raina451 wants to merge 1 commit into
Raina451 wants to merge 1 commit into
Conversation
…irect modes
Public mode built its own request (`{ inputArguments }`) and returned the
gateway response untransformed while casting it to `ProcessStartResponse[]`,
so a public app and a direct app got different shapes from the same call.
Public mode now builds the same `{ startInfo }` body via `transformRequest`
and reads the response through the same mapping as the direct path, which
also makes the existing cast honest. The Apps service keeps ownership of
nothing but the gate and the forward.
Generated with Claude Code
Co-Authored-By: Claude <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.
this pr makes public (anonymous) mode use the same request and response shape as the direct path, so the Apps service can stay a thin gate instead of owning its own contract.
stacked on #645 (SDK public mode).
the problem
public mode built its own body (
{ inputArguments }) and returned the gateway response untouched, then cast it toProcessStartResponse[]. the direct path meanwhile builds{ startInfo }viatransformRequestand maps the response back throughProcessMap. so the sameprocesses.start(...)call gave a public app raw PascalCase Orchestrator json and a direct app the camelCase typed model. the cast was quietly lying.it also pushed the shaping onto the server: apps had to hand-build
ReleaseKey/startInfoper endpoint, which means the request contract lives in two repos and drifts.what this does
public mode now runs the same transform on both ends:
{ startInfo: transformRequest(request, ProcessMap) }, same as direct.toProcessStartResponseshelper, so the cast is honest.PublicAppClientis now transport only. it posts the body as given and returns the response as given.why apps stays thin
with the SDK owning the shape, the integration endpoint only has to gate and forward: fence the process, check the body's
releaseKeyis the process it just fenced (so a fenced route can't start a different one), attach the app token + folder, forward untouched, stamp the job for the session. no per-method body building on the server, and no SDK dependency in the backend.paired change
apps side is UiPath/business-apps-jamjam#18118 — it moves to accepting
startInfoand forwarding as-is. these two need to land together since they share the wire contract.tests
public-app-client.test.tsupdated for the pass-through body; the direct-pathprocesses.test.tssuite is unchanged and still green (33 passed).