feat:mapping start context

[two-Gee]

Have you...

• Added relevant entry to the change log?

[hyperspace-insights]

Summary

The following content is AI-generated and provides a summary of the pull request:

---

Feat: Filter Process Start Context by Process Definition Inputs

New Feature

✨ Changed the behavior when no @bpm.process.start.inputs annotation is defined. Instead of fetching the entire entity row (*), the process start context is now filtered by matching the entity's fields against the ProcessInputs type defined in the corresponding process service definition. If no fields match, an empty context {} is sent.

Changes

• lib/constants.ts: Replaced NO_PROCESS_INPUTS_DEFINED log message with PROCESS_INPUTS_FROM_DEFINITION to reflect the new behavior.
• lib/handlers/processStart.ts:
  • Replaced wildcard (*) fallback with a call to the new resolveColumnsFromProcessDefinition function when no input annotations are defined.
  • Added getProcessInputFieldNames to look up the ProcessInputs type elements from the CDS model definitions using the process definition ID.
  • Added resolveColumnsFromProcessDefinition to filter entity fields against those found in ProcessInputs, falling back to ['*'] only if the process definition is not found.
  • Imported PROCESS_PREFIX constant for process definition lookup.
• lib/handlers/utils.ts: Added an early return of {} in fetchEntity when the columns array is empty, preventing unnecessary DB queries when no matching fields are found.
• tests/bookshop/package.json: Registered two new external process service fixtures (StartNoInputProcessService, StartNoInputWithAssocProcessService) for integration testing.
• tests/bookshop/srv/external/startNoInputProcess.cds: New test fixture defining a process service with ProcessInputs { status, origin }.
• tests/bookshop/srv/external/startNoInputWithAssocProcess.cds: New test fixture defining a process service with ProcessInputs { ID, status, author_ID }.
• tests/bookshop/srv/annotation-service.cds: Updated test entity comments and added a new StartNoInputZeroMatch entity (Test 16) to cover the case where no entity fields match ProcessInputs.
• tests/integration/annotations/processStart-input.test.ts: Updated Test 1 and Test 14 assertions to reflect the new filtered behavior, and added Test 16 verifying that an empty context {} is sent when no entity fields match ProcessInputs.

---

• 🔄 Regenerate and Update Summary
• ✏️ Insert as PR Description (deletes this comment)
• 🗑️ Delete comment

PR Bot Information

Version: 1.18.10 | 📖 Documentation | 🚨 Create Incident | 💬 Feedback

• Event Trigger: pull_request.opened
• Summary Prompt: Default Prompt
• LLM: anthropic--claude-4.6-sonnet
• Output Template: Default Template
• Correlation ID: d98033a0-2203-11f1-9a70-ffd21ca5a08a

---

💌 Have ideas or want to contribute? Create an issue and share your thoughts with us!
📑 Check out the documentation for more information.
📬 Subscribe to the Hyperspace PR Bot DL to get the latest announcements and pilot features!

Made with ❤️ by Hyperspace.

[hyperspace-insights]

The PR introduces a meaningful improvement by resolving process context fields from the process definition's ProcessInputs type when no inputs annotation is present, but has several correctness issues that need attention before merging: the @bpm.process.start.if condition is silently bypassed when the zero-match path is hit (the most critical bug), the startSpecs.id! non-null assertions could pass undefined through without any diagnostic, and the test fixture for Test 16 shares a definition id with Test 1 making it structurally fragile.

PR Bot Information

Version: 1.18.10 | 📖 Documentation | 🚨 Create Incident | 💬 Feedback

• Event Trigger: pull_request.opened
• LLM: anthropic--claude-4.6-sonnet
• Correlation ID: d98033a0-2203-11f1-9a70-ffd21ca5a08a

[hyperspace-insights]

Logic Error: Non-unique definitionId lookup may return the wrong service's ProcessInputs

getProcessInputFieldNames iterates cds.model.definitions and stops at the first entry where def[PROCESS_PREFIX] === definitionId. The same definitionId string can be shared across multiple entities with different @bpm.process.start.id values (e.g. annotation-service.cds has both StartNoInput and StartNoInputZeroMatch annotated with id: 'startNoInputProcess'). More critically, the loop is looking for the service-level @bpm.process annotation, but two independent services could theoretically carry the same process id, or the iteration order of definitions could pick the wrong one first.

Additionally, the lookup associates the service name with the definition id, then constructs ${serviceName}.ProcessInputs. If two services share a definition id, the resolution is non-deterministic and the wrong ProcessInputs type may be used, leading to silently wrong column filtering.

Should either enforce that definition-id uniqueness is assumed at a higher level (and add a warning when duplicates are found), or re-think the lookup so it doesn't silently use the first match when duplicates exist.

---

Please provide feedback on the review comment by checking the appropriate box:

• 🌟 Awesome comment, a human might have missed that.
• ✅ Helpful comment
• 🤷 Neutral
• ❌ This comment is not helpful