Skip to content

Conversation

@skaerg
Copy link
Contributor

@skaerg skaerg commented Jan 21, 2026

@skaerg skaerg requested review from P4uline and clarktsiory January 21, 2026 17:57
Copy link
Contributor

@clarktsiory clarktsiory left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 as a temporary fix, there is some I/O cost to this when looking up the setting, but the architecture of this plugin is like this...

Just some suggestion to avoid the flatMap + if

Comment on lines 246 to 249
configService
.rudder_workflow_enabled()
.flatMap(workflowEnabled => {
if (workflowEnabled) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ZIO#whenZIO can be used for that purpose and to avoid hurting the readability because of additional nesting and different syntaxic control flow

@clarktsiory
Copy link
Contributor

I also changed my mind on this, I think the check should just be removed : it seems to be part of an architectural issue of having an overriding workflowService during plugin initialization + a boolean setting for the status of the plugins.

In any cases, the internal endpoints are GET endpoints only, so I don't see any security issues if removing the checks.
If the plugin is there, then the API may be accessible : it seems simple enough like this.

However, after fixing this, we will need to better understand why this is causing other issues, like opening a new change request that fails depending on the setting value during plugin initialization (this needs another ticket)

@skaerg
Copy link
Contributor Author

skaerg commented Jan 22, 2026

Commit modified

@skaerg skaerg force-pushed the bug_28138/error_workflow_api_is_not_available_upon_trying_to_view_any_change_request_page branch from c2b3d09 to 88f8103 Compare January 22, 2026 13:57
@skaerg
Copy link
Contributor Author

skaerg commented Jan 22, 2026

Commit modified

@skaerg skaerg force-pushed the bug_28138/error_workflow_api_is_not_available_upon_trying_to_view_any_change_request_page branch from 88f8103 to b2977b3 Compare January 22, 2026 14:17
Copy link
Contributor

@clarktsiory clarktsiory left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some dependency still need to be fixed, thanks to @VinceMacBuche, the actual issue is about the workflowService

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like the main issue for why the WorkflowInternalApiImpl will not return workflows as expected : when the webapp starts with the "default" noop workflow service, this implementation will not be able to do anything, even if the service is supposed to be changed at runtime.

@VinceMacBuche pointed out the solution for this : it should be a WorkflowLevelService instead of a WorkflowService

@@ -159,10 +158,6 @@ class WorkflowInternalApiImpl(
// Checks if external validation is needed
def checkWorkflow: Boolean = workflowService.needExternalValidation()
Copy link
Contributor

@clarktsiory clarktsiory Jan 29, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the checks are removed, so this is not needed anymore

@skaerg
Copy link
Contributor Author

skaerg commented Jan 29, 2026

Commit modified

@skaerg skaerg force-pushed the bug_28138/error_workflow_api_is_not_available_upon_trying_to_view_any_change_request_page branch from b2977b3 to 49014b8 Compare January 29, 2026 14:34
@skaerg skaerg requested a review from clarktsiory January 29, 2026 14:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants