[APPS][Connections Part 8] Traverse backend module graph for connection IDs

[sdkennedy2]

Motivation

Use the backend-build module graph from #353 and the reusable walker from #364 to find action-catalog calls in reachable backend helper modules.

Changes

This PR adds the connection-ID-specific layer on top of the collected module graph and reusable graph walker. It introduces extractConnectionIdsFromModuleGraph and createBackendConnectionIdCollector, then wires graph-derived allowlists into production upload and dev backend execution.

The traversal starts at the real backend entry module, visits reachable app-local modules through walkModuleGraph, and runs the existing same-module connection ID extractor against each reached module. Connection ID values must still be defined in the same module as the action-catalog call site. Imported connection ID values are intentionally unsupported in this PR and continue to fail closed.

QA Instructions

Updated focused unit coverage for reachable helper modules, same-module connection ID values, graph cycles, unsupported graph shapes, production manifest enrichment, and dev execution allowlists. Also ran apps plugin typecheck and scoped lint coverage for the graph extraction and Vite integration paths.

Blast Radius

This changes apps plugin backend connection ID analysis for upload and dev execution by using reachable backend build modules instead of only the backend entry file. It preserves conservative fail-closed behavior and does not add imported connection ID value tracing yet.

Documentation

• PR Description Guidelines

[sdkennedy2]

• [APPS][Connections Part 8] Traverse backend module graph for connection IDs #362 : 2 dependent PRs (#363 , #365 ) 👈 (View in Graphite)
• [APPS][Connections Part 7] Add reusable module graph walker #364
• [APPS][Connections Part 6] Build backend module graph during backend builds #353
• [APPS][Connections Part 5] Move apps Vite behavior into getVitePlugin #357
• [APPS][Connections Part 4] Resolve same-module connection ID object values #354
• [APPS][Connections Part 3] Resolve same-module connection ID constants #351
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

[sdkennedy2]

Essentially this allows us to support in the future traversing modules to find the connectionId. Currently the connection id needs to be defined in the same module as the action-catalog function call.

[sarenji]

In effect, if the user keeps adding to their backend, parsing connection IDs will slow down the more modules they add?

[sdkennedy2]

Per unique backend function entry that is correct (since we do a build per backend function).
I figured we could start simple so its easy to reason about and the iterate and performance optimziations.

[sdkennedy2]

@codex review
@cursor review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. What shall we delve into next?

ℹ️ 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".

[sarenji]

In effect, if the user keeps adding to their backend, parsing connection IDs will slow down the more modules they add?

[sarenji]

Non-blocker/nit, but I think mockClear is fine (generally we should be calling jest.clearAllMocks() in an afterEach anyways). IIRC, the last .mockImplementation call wins?

[datadog-prod-us1-3]

🎉 All green!

❄️ No new flaky tests detected
🧪 All tests passed

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 938eea6 | Docs | Datadog PR Page | Give us feedback!}