Skip to content
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

kie-issues#1694: Apache KIE Extended Services extension issues #2802

Merged
merged 27 commits into from
Jan 16, 2025

Conversation

yesamer
Copy link
Contributor

@yesamer yesamer commented Dec 12, 2024

Fixes apache/incubator-kie-issues#1684

In this PR:

The main issue is the "ambitious" management of the Extended Service Quarkus App lifecycle.
The original idea was to run the Quarkus application just after a DMN / BPMN file is opened in the editor and close it when all files are closed. Unfortunately, that implementation didn't consider the following scenarios:

  • Validation checks are called when the Quarkus Application is starting up and not still ready
  • Heartbeat requests are called in the same scenario described previously
  • Close and opening a single DMN/BPMN file at the same moment leads the App to reach an inconsistent state, as the request of closing and starting are launched at the same moment

For that reason, I simplified the logic: the Extended Service Quarkus App is started when a DMN / BPMN file is opened for the first time and never stopped. The original idea was indeed better from a performance and resource consumption point of view, but it requires a more complex implementation.

  • Updated node-fetch to 3.3.2
  • extendedServices.connectionHeartbeatIntervalinSecs default value changed from 1 to 10. Having a heartbeat occurring every second contributed to the reported issue
  • Introduced Debug logging
  • Improved error message management
  • Improved Configuration management
  • Improved validation call body management, using the same terminology used in JIT (backend)

@yesamer yesamer requested a review from tiagobento as a code owner December 12, 2024 15:12
Copy link
Contributor

@ljmotta ljmotta left a comment

Choose a reason for hiding this comment

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

@yesamer Thanks for your PR! I've made some comments inline.

export const enableAutoRunID = "extendedServices.enableAutorun";
export const connectionHeartbeatIntervalinSecsID = "extendedServices.connectionHeartbeatIntervalinSecs";
export const extendedServicesURLID = "extendedServices.extendedServicesURL";
const defaultExtendedServicesURL = "http://localhost:21345";
Copy link
Contributor

Choose a reason for hiding this comment

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

We should use the env value instead of hardcoding. To do so, take a look into the build/defaultEnvJson.ts file in some packages (e.g. online-editor).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@ljmotta It's a good point. I would like to retrieve that default value directly from the configuration here https://github.com/apache/incubator-kie-tools/pull/2802/files#diff-153d43651b25ee3120020fae349c9e8ed99ccf90aa15995784702244decf9499R91 to avoid duplication and a single place for that property value, do you think is a valid alternative should I consider?

Copy link
Contributor

Choose a reason for hiding this comment

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

yes, it is important to have an option to configure the url of extended services, users report issues about it #2759

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@ljmotta In the examples I checked, the env variables are accessed using the useEnv() hook, but in this case, we are not managing a React app. How can I access to env variable from "plain" typescript?

Copy link
Contributor

Choose a reason for hiding this comment

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

@yesamer That's true. the defaultEnvJson is used with the webpack transform + fetch, which isn't the case here. Now, you could use the webpack's EnvironmentPlugin to set env variables. The online-editor uses this approach to set some values inside the codebase. Take a look into the online-editor/webpack.config.ts, and search for EnvironmentPlugin. The WEBPACK_REPLACE__* values are the ones used in the codebase.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@ljmotta It should be done, there are two points to discuss:

  • I added EnvironmentPlugin in both extension-main and extension-browser. There's a way to define that once?
  • Currently, the host and the post are parametrized, In my opinion, it would be better to have the entire URL as a parameter. E.g. http protocol is hardcoded, what if the user provides its own instance using https?

Copy link
Contributor

Choose a reason for hiding this comment

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

@yesamer

  • If you need to use in both, you can set the env variables in the commonConfig variable.
  • Good point. I'm not familiar on how the user set/use the Extended Services in the VS Code extension. Is it a embeded Extended Services or the user need to manually start the server? For the extended-services-java it will always use http. If the user wants to deploy it, the user will need to make the necessary adjustments to make it available through https.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@ljmotta

Comment on lines 49 to 54
const value = vscode.workspace.getConfiguration().get(property) as T;
if (!value) {
console.warn("Property: " + property + " is missing, using the default: " + defaultValue);
}
return value || defaultValue;
};
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not sure if I followed. T can be a boolean, number or string. If is a boolean it will always be true, as it is the default value. For number, can't be 0, and string can't be ""? Or value can't be undefined? The (!value) can be tricky, please, make it explicity.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

T can be a boolean, number or string. If is a boolean it will always be true, as it is the default value. For number, can't be 0, and string can't be ""

So, if the user explicitly removes the property the default value is always returned?

Copy link
Contributor

Choose a reason for hiding this comment

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

@yesamer I just considered the calls to this method. We have just 3 on this file, each one of them with T equals to boolean, number or string. The if will be true for the cases I listed, and we will have the log. Additionally, the return will always go to the default value for the same cases:

> "" || "my_default_value"
'my_default_value'
> 0 || 25
25
> false || true
true

If the value (has the type T due your casting) can have a different type, please make it explicity. Something like: T | null or T | undefined.

@yesamer yesamer requested a review from jomarko December 12, 2024 21:54
Copy link
Contributor

@jomarko jomarko left a comment

Choose a reason for hiding this comment

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

Thank you for the PR. I am happy we improve this extension.

01

Sometimes we use extended service (singletone) and sometimes we use extended services (plural).

02

The PR description says we never stop the extended services. Should then extension-browser.ts contain const stopExtendedServicesCommandUID: string = "extended-services-vscode-extension.stopExtendedServices"; and related code? Or do we keep the option to manually stop the extended services?

No manual check done, waiting until code changes are finished.

export const enableAutoRunID = "extendedServices.enableAutorun";
export const connectionHeartbeatIntervalinSecsID = "extendedServices.connectionHeartbeatIntervalinSecs";
export const extendedServicesURLID = "extendedServices.extendedServicesURL";
const defaultExtendedServicesURL = "http://localhost:21345";
Copy link
Contributor

Choose a reason for hiding this comment

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

yes, it is important to have an option to configure the url of extended services, users report issues about it #2759

# Conflicts:
#	packages/extended-services-vscode-extension/src/configurations/Configuration.ts
@yesamer
Copy link
Contributor Author

yesamer commented Dec 17, 2024

@jomarko
01
I updated all the references to use the plural form

02
Yes, the user can close the connection using a button in the bottom bar of the editor.

@jomarko
Copy link
Contributor

jomarko commented Jan 3, 2025

Closing the model file

Hi @yesamer or anyone, should closing the dmn/bpmn file to close also the message in problems tab? Currently it seems the problems tab is not cleared if model file is closed. Is that an expected behavior?
Screenshot 2025-01-03 132148

Disable Autorun and use URL

Once I disabled the autorun and started extended services as pnpm -F @kie-tools/extended-services-java start I was not able to connect VSCode extended services extension to the extended services instance.
Screenshot 2025-01-03 133741

@yesamer
Copy link
Contributor Author

yesamer commented Jan 8, 2025

@jomarko
/cc @ljmotta @tiagobento

I'm double-checking the behavior you reported. However, I'm not fully aware of the expected behavior of this feature, so my goal is to implement a minimal use-case scenario for this extension.

@yesamer yesamer added pr: wip PR is still under development pr: DO NOT MERGE Draft PR, not ready for merging labels Jan 8, 2025
@yesamer
Copy link
Contributor Author

yesamer commented Jan 10, 2025

@jomarko I fixed the first use case you reported, Closing the model file.
The second scenario, Disable Autorun and use URL, works correctly in my local

Screen.Recording.2025-01-10.at.15.10.28.mov

@ljmotta
Copy link
Contributor

ljmotta commented Jan 10, 2025

@jomarko I'm not sure if using 0.0.0.0 is correct here, please try with localhost.

@yesamer Please let me kwown when the PR is ready for another review.

@yesamer
Copy link
Contributor Author

yesamer commented Jan 10, 2025

@ljmotta Yes, please :)

Copy link
Contributor

@ljmotta ljmotta left a comment

Choose a reason for hiding this comment

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

@yesamer Thanks for your patience, LGTM!

@yesamer yesamer removed pr: DO NOT MERGE Draft PR, not ready for merging pr: wip PR is still under development labels Jan 13, 2025
@yesamer yesamer requested a review from jomarko January 13, 2025 13:18
@tiagobento
Copy link
Contributor

Deferring my review to @jomarko, feel free to merge when approved by him and green! Thanks for the great effort here.

Copy link
Contributor

@jomarko jomarko left a comment

Choose a reason for hiding this comment

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

Thank you @yesamer , I put some comments to code inline.

One question is also what is the difference of extension-main.ts and extension-browser.ts as their content seems to be very similar.

My biggest problem is there is no vsix file produced by the PR, or am I searching inappropriately? I tried to build the extension locally: pnpm -F extended-services-vscode-extension... build:prod however in that case it seems to not work properly, I would like to use vsix produced by the CI.
Screenshot 2025-01-16 075703

Copy link
Contributor

@jomarko jomarko left a comment

Choose a reason for hiding this comment

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

Thank you @yesamer. Using the VSIX produced by the CI I was able to:

  • use extended-services extension in the auto run mode
  • use extended-services extension connecting to services started in standalone terminal

Approving the PR, however opening two points that are not blocking from the merge.

Extension info

Seems to show old information, probably it needs to be first pushed to marketplace? I do not know. Notice the ping interval value.
image

Icon

Extended-services liveness icon indicator (bottom right corner) is shown from my point of view in 'difficult to understand' way. From my point of view, in separate ticket it would be worth to do a simplification. Here is my proposal, however not sure what is opinion of others.

Once extended-services extension is installed:

  • we either show connection live icon
  • or connection not live icon
  • there should be no case icon is missing

@yesamer
Copy link
Contributor Author

yesamer commented Jan 16, 2025

@jomarko Thank you for the review, it's indeed strange the Extension info is not updated. I checked, and the default value is correct in the package.json.
Regarding your proposal with the ICON, I agree with you that should be revisited, together with other components.
We agreed with @tiagobento to invest more time on this extension in the future, based on our priorities, so it makes sense to keep track of all elements/behavior you already found during this PR review, and open a discussion of its requirements

@yesamer yesamer merged commit 52040d7 into apache:main Jan 16, 2025
15 checks passed
@yesamer yesamer deleted the kie-issues#1694 branch January 16, 2025 10:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Apache KIE Extended Services extension issues
4 participants