Refactor EndNodeTemplate configuration to deployment specific

[sthanikan2000]

Summary

This PR removes the hardcoded EndNode configuration from the workflow state machine and makes EndNode resolution template-driven.

The state machine now retrieves the EndNode template via the template provider/service instead of relying on a fixed template UUID in code. This reduces coupling, improves maintainability, and keeps EndNode behavior aligned with DB-managed workflow template data.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactoring (no functional changes)
• Performance improvement
• Other (please describe):

Changes Made

• Removed the hardcoded default EndNode template ID from state_machine.go.
• Extended TemplateProvider with GetEndNodeTemplate(ctx) and implemented it in template_service.go.
• Updated workflow node initialization logic to resolve EndNode template from DB and apply dependency mapping via template data.
• Updated service wiring (consignment_service.go, pre_consignment_service.go) to construct the state machine with both node repository and template provider.
• Updated workflow node template typing/model handling for EndNode type support.
• Updated migration seed entry to store EndNode as type END_NODE (and label as End Node).
• Updated mocks and tests (router_test.go, consignment_service_test.go, workflow_node_service_test.go, state_machine_test.go) for the new provider method and SQL expectation changes.

Testing

• I have tested this change locally
• I have added unit tests for new functionality
• I have tested edge cases
• All existing tests pass

Targeted test run completed for touched workflow packages: 80 passed, 0 failed.

Checklist

• My code follows the project's style guidelines
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have checked that there are no merge conflicts

Related Issues

#174

Additional Notes

• This PR is split across two commits: the core refactor and a follow-up commit to align mocks/tests with the new template provider interface.
• EndNode is now treated as a first-class template type and no longer handled as a hardcoded internal special case in state machine initialization.

Deployment Notes

Ensure the DB migration/seed state includes the EndNode workflow template (END_NODE) in environments where initialization depends on template lookup.

[gemini-code-assist]

Summary of Changes

Hello @sthanikan2000, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request aims to improve the maintainability and flexibility of the workflow engine by decoupling the EndNode configuration from the core logic. By using a template-driven approach, the EndNode behavior can be managed through database entries, aligning it with other workflow templates and reducing the need for code changes when EndNode configurations evolve.

Highlights

• End Node Configuration: The PR refactors the workflow state machine to use a template-driven approach for resolving EndNode configurations, replacing the hardcoded template ID.
• Template Provider Extension: The TemplateProvider interface was extended with a GetEndNodeTemplate(ctx) method, implemented in template_service.go, to retrieve the EndNode template.
• Workflow Node Initialization: The workflow node initialization logic was updated to resolve the EndNode template from the database and apply dependency mapping via template data.
• Service Wiring: Service wiring in consignment_service.go and pre_consignment_service.go was updated to construct the state machine with both node repository and template provider.
• Testing and Mocks: Mocks and tests were updated to accommodate the new template provider method and SQL expectation changes.

Activity

• The PR author, sthanikan2000, has made significant changes to decouple EndNode configuration from the workflow state machine.
• The changes include refactoring the template provider interface, updating workflow node initialization, and modifying service wiring.
• Extensive testing and mock updates have been performed to ensure the new implementation works as expected.
• The PR is split across two commits: the core refactor and a follow-up commit to align mocks/tests with the new template provider interface.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request effectively refactors the EndNode configuration to be template-driven, which is a great improvement for maintainability by removing the hardcoded UUID. The changes are generally well-structured and align with the goal of making the EndNode a first-class template type. I have identified a few areas for improvement, including a potential unintended API change (with implications for template-to-instance mapping), a typo, and some issues with test coverage and correctness (also related to template-to-instance mapping). Please review the specific comments for details.

I am having trouble creating individual review comments. Click here to see my feedback.

backend/internal/workflow/service/consignment_service.go (582-585)

This change removes the filtering of the EndNode from the ConsignmentDetailDTO. While the PR aims to treat EndNode as a first-class citizen, this alters the API response by exposing a node that was previously considered an internal implementation detail, as indicated by the removed comment. This could be a breaking change for API consumers. As per the rule regarding template ID to node instance ID mapping, changes in how template-driven nodes are exposed should be carefully considered for their impact on external interfaces. Was this change in the API response intentional? If so, it would be beneficial to document it.

References

1. When mapping template IDs to node instance IDs, ensure that each template ID corresponds to a single node instance. If duplicate templates are supported, the mapping should handle multiple instances or use a different resolution strategy.

backend/internal/workflow/service/consignment_service_test.go (442)

This test mock appears to be incorrect. After the consignment is marked as FINISHED, this subsequent Save operation (for appending to global context) should not use the state IN_PROGRESS. The state should remain FINISHED. This seems to be a copy-paste error in the test setup that could hide a potential bug where the consignment state is unintentionally reverted.

		WithArgs(sqlmock.AnyArg(), sqlmock.AnyArg(), sqlmock.AnyArg(), sqlmock.AnyArg(), "FINISHED", sqlmock.AnyArg(), sqlmock.AnyArg(), sqlmock.AnyArg(), consignmentID).

backend/internal/workflow/model/workflow_node.go (14)

There's a typo in the constant name. It should be WorkflowNodeTypeEndNode to be consistent with other WorkflowNode... constants in the codebase.

	WorkflowNodeTypeEndNode WorkflowNodeTemplateType = "END_NODE" // Special type for end nodes that don't correspond to a task plugin

backend/internal/workflow/service/state_machine_test.go (168)

The tests for InitializeNodesFromTemplates do not seem to cover the new logic for creating an EndNode. The state machine is initialized with a nil templateProvider, and the existing test cases do not trigger the code path where GetEndNodeTemplate would be called. As per the rule regarding template ID to node instance ID mapping, it is crucial to ensure that the logic for creating and mapping node instances from templates is thoroughly tested. Please consider adding a test case that provides a mock templateProvider to verify the EndNode creation and its dependency mapping logic.

References

1. When mapping template IDs to node instance IDs, ensure that each template ID corresponds to a single node instance. If duplicate templates are supported, the mapping should handle multiple instances or use a different resolution strategy.

[ginaxu1]

Lgtm