[APPS][WIP] Prototype direct action execution in local dev server - #483
[APPS][WIP] Prototype direct action execution in local dev server#483sdkennedy2 wants to merge 1 commit into
Conversation
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 61072dbcac
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| }); | ||
| }); | ||
| // Loading the module todos.backend.ts | ||
| const functions = await import(func?.absolutePath); |
There was a problem hiding this comment.
Load backend source through Vite instead of native import
For the normal .backend.ts/.backend.tsx inputs accepted by BACKEND_FILE_RE, absolutePath points to the uncompiled source file, but this native dynamic import bypasses Vite's TypeScript transpilation and module resolution. Under the repository's supported Node runtime, invoking any such backend function therefore fails with an unknown-file-extension or unresolved-import error; it also uses Node's module cache rather than Vite's HMR graph. Load the module through Vite's server-side loader or execute a generated bundle instead.
Useful? React with 👍 / 👎.
|
|
||
| res.statusCode = 200; | ||
| res.setHeader('Content-Type', 'application/json'); | ||
| res.end(JSON.stringify({ success: true, result } satisfies ExecuteActionResponse)); |
There was a problem hiding this comment.
Preserve the response data wrapper
When a directly invoked backend function returns a normal value such as { value: 42 }, this serializes that raw value as result, while dev-server-transport.ts:72 unconditionally returns executeActionResponse.result.data. Successful local calls will consequently resolve to undefined (or throw when the function returns undefined) instead of their actual value. Wrap the direct result as { data: result } to retain the established ExecuteActionResponse contract.
Useful? React with 👍 / 👎.
| const { functionName, args = [] } = await parseRequestBody(req); | ||
| const func = functionsByName.get(functionName); |
There was a problem hiding this comment.
Restore request validation before importing the function
For a request with a missing or unknown functionName, this lookup yields undefined and the subsequent import/invocation is caught as a generic 500. Previously validateAndBundle explicitly returned 400 for an invalid name and 404 for an unknown function, and the existing execute-action tests rely on those responses. Validate the parsed name and lookup result before attempting the direct import.
Useful? React with 👍 / 👎.

Motivation
Explore executing Apps backend functions directly in the local Vite dev server while routing action-catalog calls through Datadog's App Builder query execution API. This draft is intended to make the prototype concrete enough for design feedback before the implementation is completed.
Changes
The local
__dd/executeActionhandler now imports the requested backend module and invokes its exported function with the request arguments. Before invoking it, the handler installs an action-catalog execution adapter so calls made by the backend function can be forwarded to the App Builderpreview-asyncAPI and resolved through the existing long-polling flow.The adapter builds an action query from the action FQN and inputs, starts the query, validates the returned receipt ID, and reuses the current polling implementation to return the action output.
This is intentionally a WIP prototype. The action-catalog dependency and callback wiring are incomplete, and the Apps plugin does not currently typecheck with these changes.
QA Instructions
No manual QA yet because the prototype wiring is incomplete. For this draft, review the proposed execution flow and where the action-catalog adapter is installed in the local dev-server request lifecycle.
Blast Radius
The change is limited to the Apps plugin's local Vite development server and its backend-function execution endpoint. It is not production-ready and has no released customer impact unless completed and merged.
Documentation