-
Notifications
You must be signed in to change notification settings - Fork 27
Fixes #28138: Error "Workflow API is not available" upon trying to view any change request page #903
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: branches/rudder/9.0
Are you sure you want to change the base?
Conversation
clarktsiory
left a comment
There was a problem hiding this 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
| configService | ||
| .rudder_workflow_enabled() | ||
| .flatMap(workflowEnabled => { | ||
| if (workflowEnabled) { |
There was a problem hiding this comment.
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
|
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 In any cases, the internal endpoints are GET endpoints only, so I don't see any security issues if removing the checks. 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) |
|
Commit modified |
c2b3d09 to
88f8103
Compare
|
Commit modified |
88f8103 to
b2977b3
Compare
clarktsiory
left a comment
There was a problem hiding this 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
There was a problem hiding this comment.
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() | |||
There was a problem hiding this comment.
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
…view any change request page
|
Commit modified |
b2977b3 to
49014b8
Compare
https://issues.rudder.io/issues/28138