Missing dependecy in AUR package. (bc)

Hey just wanted to give a heads up that "bc" (GNU Basic Calculator) should be listed as a dependency in the AUR packages.
As per the contribution guidelines, I am tagging @AUTplayed and @m1m3-50 in this. As it is betterlockscreen will build just fine from the AUR but when run without bc on the system you are presented with.
Got 1600x900 /home/spam/.cache/i3lock/1600x900
Generating alternate images based on the image you specified,
please wait this might take few seconds...

Converting provided image to match your resolution...

Applying dim and blur effect to resized image
/usr/bin/betterlockscreen: line 213: bc: command not found
/usr/bin/betterlockscreen: line 214: bc: command not found

Caching images for faster screen locking

All required changes have been applied

This makes it so that the blur isn't properly applied to the images when caching.
Just wanted to give a heads up, really enjoying the tool and greatly appreciate your effort in developing it!
Cheers!

hi, if I'm not mistaken, bc is already a dependency in https://aur.archlinux.org/packages/betterlockscreen/ and https://aur.archlinux.org/packages/betterlockscreen-git/

Weird! Could have sworn I didn't see it, sorry for the false alarm. I guess maybe yay had a hiccup. Thanks again for the awesome tool :)


Typos in two values of the SatErrorResp.ErrorCode enum

Note the same typo in two instances of MISSMATCH below
https://github.com/electric-sql/electric/blob/b2e7ab6d74def0bb0dbbaa990d4612a21241b5fa/protocol/satellite.proto#L85-L93
Fixing them in a backwards-compatible way should be as simple as
 enum ErrorCode {
+    option allow_alias = true;
     INTERNAL = 0;
     AUTH_REQUIRED = 1;
     AUTH_FAILED = 2;
     REPLICATION_FAILED = 3;
     INVALID_REQUEST = 4;
+    PROTO_VSN_MISMATCH = 5;
     PROTO_VSN_MISSMATCH = 5;
+    SCHEMA_VSN_MISMATCH = 6;
     SCHEMA_VSN_MISSMATCH = 6;
 }

Closed in https://github.com/electric-sql/electric/pull/257


Adds more flexibility for retrieving components

This commit passes the context object as a 2nd arg to
getComponent. The point of this is so that getComponent can have access
to the props objects as well as any other future items we decide
to pass into context.
@ljharb

LGTM - a test would be good but not a blocker


Deploy marketplace

figure out if CORS issue with connecting marketplace UI <> registry
set up behind subdomain (clearnet + tor)
build for prod

duplicate of #registry/51


Repository filter does not show up in sidebar when in "Watched repositories" section

That's a bit confusing since the sidebar changes. The "Filter by repositories" entroes should be there all the time. Otherwise you need to click twice to get there.

I consider "watched repositories" view as completely separate, it even contains list of repositories in main area, so showing repository filter which relates to unread notifications in sidebar on this view is meaningless for me. I can imagine to show sidebar there, but use it to contain list of organizations for watched repositories, and allow to filter watche repositories by organizations, which may be usefull for user with lots of watched repositories.

"Filter by repositories" moved out of navigation drawer in Material design, so this isssue is obsolote now.


Separate Pip and Github Installation Instructions and write a tutorial for each.

The tutorial says "In your working directory, create a data folder, and copy this demo-rasa.json file there."
I have done this.
Then: "Create a file called config_spacy.json or config_mitie.json, depending on the pipeline selected, in your working directory which looks like this"
I have copied the config_spacy.json just as required (and put it in my working directory). The config_spacy.json provided is as follows:
{
"pipeline": "spacy_sklearn",
"path" : "./models",
"data" : "./data/examples/rasa/demo-rasa.json"
}
Now this appears to be designed for someone working directly in the cloned repository -- why was I instructed to create a data folder in my "working directory" when a data folder already exists in the repository -- with the data! Seems half the tutorial was written for someone working in a new project folder, and the other half assumes you're working directly within the cloned repository.
Then: "python -m rasa_nlu.train -c sample_configs/config_spacy.json" -- again, this is written for someone working directly in the cloned repository which doesn't seem to relate to the tutorial that earlier instructed me to create a /data folder that would already exist in this cloned repository.
Furthermore, this command failed even when used in the cloned repository -- no default model was used and I was given an error:
"Exception: Failed to load spacy language model for lang 'en'. Make sure you have downloaded the correct model (https://spacy.io/docs/usage/)."
The tutorial says nothing about downloading a model.

Also after downloading the default 'en' model (which the tutorial never told me was required) and getting the model to finish training and save, the server does not seem to persist or function in any way after completing training. I just get "INFO:main:Finished training".
Any requests to the server as instructed return:
curl: (7) Failed to connect to localhost port 5000: Connection refused

Sorry @Godrek which tutorial are you referring to, this one? http://rasa-nlu.readthedocs.io/en/latest/tutorial.html

Sorry for not specifying -- yes that is the one.  (http://rasa-nlu.readthedocs.io/en/latest/tutorial.html)
I followed the installation instructions in the prior page as well (http://rasa-nlu.readthedocs.io/en/latest/installation.html) using pip to install all of the required libraries: rasa_nlu, spaCy, scikit-learn, scipy

python -m rasa_nlu.train -c sample_configs/config_spacy.json doesn't start a server, it just call Rasa NLU from the python interpreter to rain a new model and close. You may be interested in (using Rasa NLU HTTP server)[http://rasa-nlu.readthedocs.io/en/latest/http.html#running-the-server].

Per the docs here:

The recommended way to install rasa NLU is using pip:

Thus, the tutorial is written assuming that people did it this way. And if they downloaded from GitHub/bleeding edge then they are familiar enough with Rasa and how it works to adapt the tutorial accordingly.
Also per the docs here is where the spacy model would've gotten downloaded.
I'm the one who modified the command in this section of the tutorial so you have me to thank for the confusion. I had moved the configs to the sample_config directory and went around everywhere a config file was mentioned to add the sub-directory. But in this case it doesn't apply since the tutorial is written in the mindset of downloading from pip.
In the end though, I think what you're saying is that the docs: written to address both GitHub + pip + docker are confusing. And we should likely break them out more discretely.

To install via pip follow these instructions
To install via GitHub follow these instructions
To install via Docker follow these instructions

I'll rename this issue and leave it open to see if someone wants to help make things clearer.

I'm sorry for the originally hostile title -- I was mildly frustrated.
Clearly I missed the line:
"python -m spacy download en"  and that is my bad. I also missed the difference in the commands using rasa_nlu.train and rasa_nlu.server -- again my fault (the commands looked so similar because they use the same config, but I was just frustrated and in a hurry -- apologies)
If nobody gets around to making things clearer I'll try to step up and see if there is anything I can do after I finish getting everything working.
Sorry for the hostile title, thanks for the help

I'm pretty certain we've all experienced that frustration so no worries. Thanks for the offer to try and help, once you've used it for so long it's easy to overlook the initial startup problems.
Are you up and running now?

I did get it working, thanks.

How should I create the config_spacy.json file? I installed everything using pip. I am getting error upon running this
{
"pipeline": "spacy_sklearn",
"path" : "./models",
"data" : "./data/examples/rasa/demo-rasa.json"
}
could someone help please.

@Pari-singh What is the error you are getting? And what is the command you are using with the config_spacy.json file?

{
"error": "No model found with alias 'default'. Error: Failed to load model metadata. [Errno 2] No such file or directory: '/home/paridhi/./models/default/metadata.json'"
}
This is what I am getting upon running
$ curl -XPOST localhost:5000/parse -d '{"q":"I am looking for Chinese food"}' | python -mjson.tool
In the tutorial, it was asked to create a file config_spacy.json in the working directory.
I did that, but I diidnt get what path is, in the mentioned .json file because I dont have any .\model path in my system.

@Pari-singh did you install from GitHub or pip?
Also, did you train any data either via the /train endpoint or the command line python -m rasa_nlu.train -c sample_configs/config_spacy.json

@Pari-singh  The trained model should be generated within the folder: /home/paridhi/./models/
The default folder name uses the timestamp.  You can change the folder name to "default" so that make sure that there is one model as default.

Yes, got it running... yeah it was the default folder location which was causing the error...
Thanks @osswangxining and @wrathagom

How do you upload a model once it is trained and saved ??

This is not related to this issue, please create a separate issue for your question.


Elements with commas not supported

When downloading a file where one of the elements may contain a comma, the file is downloaded incorrectly unless a custom separator is provided that is not a comma. The problem with this is that the file would no longer be a CSV.
I believe the problem would be resolved by updating your joiner() function in src/core.js to be:
export const joiner = ((data,separator = ',') =>  data.map((row, index) => row.map((element) => "'" + element + "'").join(separator)).join(\n) );

I have a pull request open that resolves this problem.

Great.. I am reviewing it.


[JAV-286]add protect feature when call remote calls in bean initializ…

…ation

Coverage increased (+0.03%) to 85.42% when pulling 2e69f2b1bf474bf320d33b96dc159231d846eddf on liubao68:call into 77b4718f4456ee9f88177020bd68212f2e416479 on ServiceComb:master.

Coverage increased (+0.04%) to 85.426% when pulling e123d8df530d8cddbc984db645f364da60764182 on liubao68:call into 77b4718f4456ee9f88177020bd68212f2e416479 on ServiceComb:master.


Introduce Target Based Scaling

This PR refactors the scaling logic from SqlTriggerListener class to SqlTriggerScaleMonitor and SqlTriggerMetricsProvider class.
It also introduces SqlTriggerTargetScaler for target based scaling logic.
Reference PRs:
https://github.com/Azure/azure-sdk-for-net/pull/31367
https://github.com/Azure/azure-webjobs-sdk-extensions/pull/806
ToDo

[x] Add unit tests for SqlTriggerTargetScaler
[ ] Test with runtime driven scaling on portal
[x] Test with scale controller 3.x prototype

Latest changes look good, although you have some merge conflicts to fix up here first.

@AmeyaRele - Please take a look at the open comments

@AmeyaRele Please provide screenshots/logs as requested by @chiangvincent https://github.com/Azure/azure-functions-sql-extension/pull/598#pullrequestreview-1300401704

Having some issues with running it on local functions host, syncing up with Vincent offline to fix them.

@AmeyaRele FYI - in preparation for input/output binding GA we've switched trigger stuff back to a separate branch (release/trigger). I've switched this to target that new branch instead so nothing should change, just letting you know in case you need to make any more changes.

@chiangvincent Please do take a look at the PR and the attached screenshot. I have addressed all your comments from the last review

@AmeyaRele - Chatted with Alexey offline about the logging and we're going to investigate and address that separately. So you're good to merge this in whenever you're ready to and we'll take care of following up about the logging stuff.


gradle build for android studio?

gradle build for android studio?

+1

+1

+1

I've forked and made a gradle build for the command line tools, shouldn't be very difficult to make it work on Android Studio. It's on jsteinaker/aFileChooser in case you need it.

+1

+1

@jsteinaker Thanks, will have a look into it.

+1

+1

Here's gradle build file build.gradle
`apply plugin: 'com.android.library'
android {
compileSdkVersion 23
buildToolsVersion "23.0.2"
lintOptions {
    abortOnError false
}
defaultConfig {
    minSdkVersion 7
    targetSdkVersion 22
}

buildTypes {
    release {
        minifyEnabled false
        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.txt'
    }
}

}
dependencies {
compile 'com.android.support:support-v4:23.1.1'
}
`

compile 'andhradroid.dev:aFilechooser:1.0.1'

Thanks, I'll give it a try.

@kashban It should work :) , I used it successfully.

@yduman I believe you :-). Unfortunately there was a change in the API between the library version I use and this one. And it does not seem to adhere mimetype filtering which I require. So I will probably ditch afilechooser alltogether and go for Android standard, since I upped my minSDK version to API 19.


tvdb_list stopped working

Version Number
1.18
What branch are you on?
master
Describe the Bug
since recently (tvdb page has change and it might explain) tvdb_list is not gathering tvdb ids.
Relevant Collection/Overlay/Playlist Definition
tvdb_list: https://thetvdb.com/lists/indiana-jones
returns:
TVDb Error: No TVDb IDs found at {tvdb_url}

Logs
https://gist.github.com/Nexius2/ba5c61fae1f7dc02f2f1a23832edbe65

this is fixed in nightly


Fix cni conflist handling

This is done by following current kubelet behavior more closely.
The problem became apparent with Flannel 0.9.1 update which
made use of 'portmap' plugin which is configured in a single
conflist file with the main 'flannel' plugin.
As portmap is needed for hostPort feature, there's high possibility that
other CNIs could become broken soon.

This change is

Reviewed 2 of 2 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

Review status: all files reviewed at latest revision, 1 unresolved discussion.

pkg/cni/client.go, line 32 at r1 (raw file):

type Client struct {
	cniConfig *libcni.CNIConfig
	netConfig *libcni.NetworkConfigList

Maybe better name would be there netConfigList? We are using constantly in other parts of code name netConfig for unmarshaled cni result.
WDYT?

Comments from Reviewable

Review status: 1 of 2 files reviewed at latest revision, 1 unresolved discussion.

pkg/cni/client.go, line 32 at r1 (raw file):
Previously, jellonek (Piotr Skamruk) wrote…
Maybe better name would be there netConfigList? We are using constantly in other parts of code name netConfig for unmarshaled cni result.
WDYT?

Done.

Comments from Reviewable

 again ;)

Reviewed 1 of 1 files at r2.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


closes #35

Hi @tnrich I think the thing that fails is unrelated to my change

@manulera thanks I'll check it out

Merged and published! Thanks @manulera !


NumberInput - add currency / unit functionality

The input component should also have funcitonality to choose a unit i.e. currencies like USD or EUR for the input

Unit functionality is already in the number input component, for the new unit selection input we have a follow up task: #304


fix: rename asyncStoragePersistor to createAsyncStoragePersistor

Why
This function was being called as createAsyncStoragePersistor in the docs but was exported as asyncStoragePersistor

Yes, I found out that just today and also asyncStorageKey storage persistor options is just key in the codes. So, might need to fix the doc or fix the codes. I think changing the doc is easier approach but the overall naming will be a bit off. Any take on this?

I found another issue. The storage parameter in CreateAsyncStoragePersistorOptions has AsyncStorage type, but the AsyncStorage object imported from @react-native-async-storage/async-storage has AsyncStorageStatic  type, so there is an incompatibility when building the persistor by following the documentation:
import AsyncStorage from '@react-native-async-storage/async-storage';
import { createAsyncStoragePersistor } from 'react-query/createAsyncStoragePersistor-experimental';

const asyncStoragePersistor = createAsyncStoragePersistor({
  storage: AsyncStorage,
});

Thanks @Aung-Myint-Thein @maylinmedina for pointing it out. I think it should be good now. can you guys take a look again?

@brunohkbx  Looks good to me. Thanks.

I'm eagerly awaiting these changes :D wanna test it out in my build.

I'm eagerly awaiting these changes :D wanna test it out in my build.

Oh you can actually test out this in the codes. The discussion here is just for naming consistency :D Please let us know where you have problems and I can help out.

:tada: This PR is included in version 3.19.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Decode returned code VP8_STATUS_UNSUPPORTED_FEATURE

File file = new File("ezgif.com-gif-maker.webp");
Thumbnails.of(file).scale(0.5).toFile(file.getAbsolutePath() + ".thumbnail.jpg");

Could you provide more detail of the code? I don't know what is Thumbnails.

Could you provide more detail of the code? I don't know what is Thumbnails.

Hi nintha,
Thumbnails libraray:
net.coobird:thumbnailator:0.4.8
I want to scale a webp picture ezgif.com-gif-maker.webp to half.

This project just wrap java code and dll files. You may go to source repo luciad/webp-imageio , and create issue about supporting new feature of animation webp.


Memories w/ Nextcloud

Wonder if memories belongs here; could use some better visibility. Basically we've have feature parity with Nextcloud Photos now, except a couple of minor things.

I agree! I'm just not sure how to present it. Does it get its own column? If so do the Nextcloud mobile apps count for the mobile features. I'm trying to figure out the best way to accurately include it in the list.

Not sure! It does leverage the most important part of the Nextcloud mobile apps, i.e. auto upload. But the UI is still unfortunately separate (albeit very responsive).

@pulsejet I've added Memories. If you have any suggested changes to my suggested scores, please let me know.

Thanks!

@meichthys I just happened to look at this list again and do have some questions. I mainly compared Memories to Immich since they're closest in terms of feature set.
Please note that I don't intend to complain; just trying to understand the reasoning behind the scoring.

Video support - How does Immich get 8/10 without transcoding support? AFAIK you can't even play e.g. HEVC on Immich in the browser yet (https://github.com/immich-app/immich/issues/203), neither is streaming adaptive. Although support for Memories is new, Photoprism still gets 7/10 despite supporting transcoding since a while?
Object/face recognition: Immich has the same score as Memories/Photoview/Nextcloud Photos despite not supporting face recognition at all? (https://github.com/immich-app/immich/issues/294)
Timeline: Immich 9/10, Memories 8/10. Why? IMHO (at least in the webapp) the memories timeline is much better. E.g. try skipping to a past position in the timeline in both apps and scroll up; immich (at least in the demo) is quite janky for me while memories is very smooth. Also unless I missed something Immich shows square thumbs only.
Multiple user support: anything based on Nextcloud has way better support for this compared to anything else. Nextcloud integrates with many auth frameworks for "real" multi-user support.
EXIF Data: I'm a bit confused why Memories has 3/10. What important feature is it missing that other apps support?
Automatic upload: Trying to figure out what the Nextcloud app is missing in uploads. I've been using it for a few months now and haven't run into any issues whatsoever.

In general, I feel the list is a little biased in favor of Immich. But that's just my opinion.

@pulsejet Thanks for your input. My scores are primarily based off the Demos that each project provides. I understand that the demos may not be fully representative of all features of the project, resource usage, etc, but that's really all i have to go on since i don't have the hardware or time to run an self-hosted instance of each. I'm glad to change the subjective measure based off of input like yours.
(I try not to be as fair as possible even though I currently use Memories as my primary photo library 😉. Perhaps that makes me be a bit more aware or critical of the Memories deficiencies)

Video support was primarily based on my experience in the demos, not necessarily on transcoding. The Immich scoring was primarily based off the mobile app (not the browser). The Immich mobile app didn't seem to have any troubles playing any of the media files - I'm not sure how it does it without transcoding. 🤷♂ I'm on memories v4.7.2 and still can't seem to play most videos. It may be a configuration issue on my end, but if it does require involved configuration, then I think that should result in a lower subjective score. (I haven't been able to use the Memories demo to test this, so i'm reliant on my own instance)
You are definitely correct here. I was looking at this yesterday and realized that the Immich rating is probably too high. I think it does support object detection, but not face detection yet. (perhaps object/face detection should be broken out into separate features). The memories 8/10 rating was probably prior to some of your recent changes that improved the functionality. I've made an issue here for the immich adjustment.
I think the immich demo is currently down but i will test this. Again, I was using the mobile app for rating this feature since that's where the majority of Immich useres interact with the photos (IMO, the mobile app is significantly better than the web app - although it has been getting close to feature parity in recent releases).
Again, you are correct on this for sure. Not sure why it was a 7 on Nextcloud/Memories to start. Will fix shortly.
The Memories rating is old. This should be increased (pull request would be appreciated!). Other apps do allow modification to different exif fields (more than just the date), but like you indicated, 7 for immich is probably a stretch.
This can also probably be increased for Nextclou/Memories now. Before this week, the ios nextcloud mobile app required the app to be open for the photos to upload (i think the android app may work better). Either way, there are alot of peopleon android and ios that complain about the nextcloud auto-uploads). For me the uploads now work automatically in the background on iOS since the latest v<IP_ADDRESS> nextcloud ios update.

As for being biased toward Immich, it may be due to the fact that Immich has submitted their own pull request to this repo (Unless I have a real good reason to bump the subjective score down, i generally leave it as is to encourage more pull requests.) Also, the mobile app experience which is quite polished may help the user gloss over some deficiencies at first glance.
In summary, I'm the one who ends up having to give a subjective rating and i realize that means I'm probably the bad guy to one project or the other. I'm just a single tester trying to give an accurate as possible view of the options that are out there, so input like yours helps a lot.

@pulsejet Thanks for your input. My scores are primarily based off the "out of the box" experience that the Demos for each project provides. I understand that the demos may not be fully representative of all features of the project, resource usage, etc, but that's really all i have to go on since i don't have the hardware or time to run an updated, properly-configured, self-hosted instance of each.

Yup, that's my source of knowledge as well. Btw, I realised I didn't mention thanks for maintaining this in the first place 😄

Video support was primarily based on my experience in the demos, not necessarily on transcoding. The Immich scoring was primarily based off the mobile app (not the browser). The Immich mobile app didn't seem to have any troubles playing any of the media files - I'm not sure how it does it without transcoding. 🤷♂ I'm on memories v4.7.2 and still can't seem to play most videos. It may be a configuration issue on my end, but if it does require involved configuration, then I think that should result in a lower subjective score. (I haven't been able to use the Memories demo to test this, so i'm reliant on my own instance)

Native apps don't have many limitations unless you're running older hardware or your bandwidth bottlenecks (then you need adaptive streaming like memories does). I agree transcoding is a lot of extra config (suggest filing an issue if it isn't working), but that's unfortunately thanks to Intel and NVIDIA not making life any easier 😞. Apps like Jellyfin get it easier when deployed with Docker since they're geared towards media in the first place (Nextcloud isn't, yet) so they can include some non-free components in the image.
As for the demo, that instance isn't going to do any transcoding anyway 😄

I think the immich demo is currently down but i will test this. Again, I was using the mobile app for rating this feature since that's where the majority of Immich useres interact with the photos (IMO, the mobile app is significantly better than the web app - although it has been getting close to feature parity in recent releases).

I didn't mean to say the Immich timeline has problems. All I'm trying to understand is why Memories has a lower score. (IMHO, Memories timeline is as good as Google Photos if not a bit faster).
To be fair, some of my evaluation points are from the POV of a developer rather than a user. For example, a justified layout in a timeline view is the most complicated part of the Memories codebase (but nowhere close to the most useful). Having square thumbnails is much easier since it lets you predict where each photo will be simply by knowing the total number of photos in each section. As soon as the size of thumbnails becomes variable, this turns into a very complex problem. Which is exactly why no other FOSS photo library (that I know) has a timeline view supporting both scrubbing and a justified layout simultaneously.

This can also probably be increased for Nextclou/Memories now. Before this week, the ios nextcloud mobile app required the app to be open for the photos to upload (i think the android app may work better).

I don't know why stuff keeps breaking in the Nextcloud apps honestly ... It's not like the WebDAV API has changed (at all) 😶. Just that 4 seemed a bit low. I do use Android btw.

As for being biased toward Immich, it may be due to the fact that Immich has submitted their own pull request to this repo (Unless I have a real good reason to bump the subjective score down, i generally leave it as is to encourage more pull requests.) Also, the mobile app experience which is quite polished may help the user gloss over some deficiencies at first glance.
In summary, I'm the one who ends up having to give a subjective rating and i realize that means I'm probably the bad guy to one project or the other. I'm just a single tester trying to give an accurate as possible view of the options that are out there, so input like yours helps a lot.

I don't blame anyone for the bias I felt; as I said it's just my opinion anyway. Just wanted to point out some of the things (e.g. face recognition and exif) where it seemed not obvious to me why Immich had a high score.

@pulsejet keep up the great work! I've updated the subjective measures to bring things up to date for Nextcloud/Memories. Let me know if you have any other suggestions, and please feel free to submit pull requests when/if changes are made.


FIX: Fix new PEP8

Coverage remained the same at 72.48% when pulling cd4d837b8d6ecc938ad9ab5ed0790b45507ade9e on Eric89GXL:fix-flake into b27896e1b2a345ce09d8f054af2dd82ba9f28a75 on nipy:master.

all better


ALF Automation

Brackets: Please merge this pull request created by ALF. @ArturOledzki @pantkowiak @rajjain  @tasunil FYI

@ArturOledzki @pantkowiak @rajjain @tasunil Please re target this PR to release branch.

Closing as superceded by https://github.com/adobe/brackets/pull/13716
When release will be merged back to master we will have this.


An error is reported when the script is running

root@kent:~/CVE-2021-22005-exp# python3 vcenter_saml_login.py -p data.mdb -t xxx.xx.xxx.xxx
[] Successfully extracted the IdP certificate
[] CN: cn=TrustedCertChain-1,cn=TrustedCertificateChains,CN=e4ed3720-803d-4d2e-bbd1-3b5221182357,CN=Ldus,CN=ComponentManager,DC=vsphere,DC=local
[] Domain: vsphere.local
[] Successfully extracted trusted certificate 1
[] Successfully extracted trusted certificate 2
[] Obtaining hostname from vCenter SSL certificate
[] Found hostname vcenter.tech.zone for xxx.xx.xxx.xxx
[] Initiating SAML request with xxx.xx.xxx.xxx
[] Generating SAML assertion
[] Signing the SAML assertion
[*] Attempting to log into vCenter with the signed SAML request
[-] Failed logging in with SAML request
Traceback (most recent call last):
File "/root/CVE-2021-22005-exp/vcenter_saml_login.py", line 350, in
c = login(args.target, s)
File "/root/CVE-2021-22005-exp/vcenter_saml_login.py", line 300, in login
raise Exception("expected 302 redirect")
Exception: expected 302 redirect
xxx.xx.xxx.xxx Is an Internet IP

Hello, in newer versions of vCenter they have added a new request parameter that we have not tested well enough that will cause this behavior. If you check out the pull request here, #13, I believe it may address your issue.

Traceback (most recent call last):
File "/root/CVE-2021-22005-exp/vcenter7.0.3_saml_login.py", line 354, in
req, relaystate = saml_request(args.target)
File "/root/CVE-2021-22005-exp/vcenter7.0.3_saml_login.py", line 246, in saml_request
return etree.fromstring(req), parse_qs(o.query)["RelayState"][0]
KeyError: 'RelayState'

Do you have any additional information about the version of vCenter running? Can you inspect the traffic of a normal login to ensure the requests parameters haven't changed for this version? If they have, you should be able to edit the request to include the necessary so it won't be redirected.

Do you have any additional information about the version of vCenter running? Can you inspect the traffic of a normal login to ensure the requests parameters haven't changed for this version? If they have, you should be able to edit the request to include the necessary so it won't be redirected.

I'm sorry, this is the test goal of a project I'm responsible for. The owner didn't provide me with any information about vCenter. Because I can't log in, the current information is basically not available

I am getting the 302 redirect error as well.

Hello, in newer versions of vCenter they have added a new request parameter that we have not tested well enough that will cause this behavior. If you check out the pull request here, #13, I believe it may address your issue.

This worked :)


Customizing the node confluence when tracks merge

There is now the priority feature, which allows this more or less, with an ok amount of coding effort


Fix InvalidOperationException thrown from Process.KillTree

Attempt to fix "System.InvalidOperationException : Cannot process request because the process (5064) has exited." on Windows.

:up: :date: reverted my last attempt and rebased on dev


Incremental load time is slow ~9s

Do you want to request a feature or report a bug?
Bug
What is the current behavior?
Incremental load is pretty slow, the initial load doesn't take very long (20s or so), and it's not a huge app, but the incremental load takes ~9 seconds.
If the current behavior is a bug, please provide the steps to reproduce.
CPU profile
webpack.config.js
What is the expected behavior?
It was faster in previous versions of webpack, but also the config changed
If this is a feature request, what is motivation or use case for changing the behavior?
Please mention other relevant information such as the browser version, Node.js version, webpack version, and Operating System.
Webpack 4.6
MacOS 10.13.3
NodeJS 9.11.1

A lot of the work seem to happen in optimizeChunksAdvanced:

Thanks for your report. It would be great if you reduce your issue to a small reproducible example. Best put this example into a github repository together with instructions how to get to the problem.

I wish I could do that. This is not an issue, as far as I know that is reproducible in in a small environment as everything works as expected except that it loads slower than expected.
As far as the code itself. It is not an open source project. So I cannot share the code publicly. I am happy to share anything else though. As I shared the config and the CPU profile of the incremental load.

@jfrolich can you disable/enable loaders/plugins and check perf again to ensure problem inside webpack?

Also could use https://webpack.js.org/plugins/profiling-plugin/

@jfrolich can you disable/enable loaders/plugins and check perf again to ensure problem inside webpack?

Thanks, I did some extra testing, turning on and off loaders. It looks like thread-loader was the main culprit. When removing that the incremental load became significantly faster!

From the CPU profile image it looks like the SplitChunksPlugin causes this?

@sokra It's still not sub-second as I would really like :D, but removing the thread-loader has shaved off a lot of time in incremental load so it's ok. I have no special configuration for SplitChunksPlugin, but indeed it looks like a lot of time is spent there.
But yes you can close the issue as it's good enough for me at the moment. Happy to supply more data for performance testing.

I took a look at the CPU profile. Seems really like the SplitChunksPlugin take most of the time. This probably can be improved.

Thanks! I didn't find a big difference in setting the poolTimeout:
poolTimeout: 500ms (default): ~4s
poolTimeout: Infinity: ~4s
no thread-loader: ~2.5s

I'm trying to improve the split chunks performance too. Could you give me some info about your app? Number of modules? Number of chunks?

Can you email me at jaap at cogo.ai, then I can share the whole source code. I have lazy loading on a route level with ~ 16 dynamic module imports. Then I have a code snippet component that dynamically loads syntax highlighting for ~114 languages using dynamic import. The total number of modules is 296 javascript files.

@jfrolich you try 2 things:

disable splitChunks in dev mode:

optimization: isDev ? {
  splitChunk: false
} : {}

swap thread-loader with happypack, latest beta version supports webpack v4, use 4 threads (3 is a default), from our comparison it produces better results.

@sejoker: Thank you! I am interested in the pro/cons of enabling disabling splitChunks in development? (Maybe also of interest of other people reading this issue).
Maybe it should be off by default in development?

Ok here is some early results: when using removeAvailableModules: false, splitChunks becomes very slow in some cases.


Search: Collect Feedback

The proposed Search Architecture is now published.
This issue is here for us to collect feedback from you all on how to improve the architecture to fit more use-cases. Take the opportunity to look through the Architecture diagram on the page linked above. Also take some time to read through the roadmap. Think through your use-case and add any comments to this issue.
Thanks in advance!
(The issue will be open for feedback until February 1st)

As there is no feedback yet I guess I should post some 😆 Short summary: It's great, I really looking forward to it.
Some points that are important for me, but that are all covered by the roadmap/architecture:

Have an out-of-the-box experience with an in memory index. There are a lot of implementations that allow at least a basic search. I already have some positive experience with lunr.
Similar important is having support for a real search engine like elasticsearch.
Being able to index any kind of content (not limited to entities), or no 1-to-1 relationship to entities. We are looking forward to build an index for the API docs plugin, by indexing the endpoints and schemas in an API definition (e.g. OpenAPI).
Custom search result cards per type #3343

I'm interested how you plan to implement the lifecycle of the index. When is indexing executed? Will it be part of the catalog processing pipeline/refresh loop?

As there is no feedback yet I guess I should post some 😆 Short summary: It's great, I really looking forward to it.
Some points that are important for me, but that are all covered by the roadmap/architecture:

Have an out-of-the-box experience with an in memory index. There are a lot of implementations that allow at least a basic search. I already have some positive experience with lunr.
Similar important is having support for a real search engine like elasticsearch.
Being able to index any kind of content (not limited to entities), or no 1-to-1 relationship to entities. We are looking forward to build an index for the API docs plugin, by indexing the endpoints and schemas in an API definition (e.g. OpenAPI).
Custom search result cards per type #3343

I'm interested how you plan to implement the lifecycle of the index. When is indexing executed? Will it be part of the catalog processing pipeline/refresh loop?

Thanks @Fox32!  We were thinking of it living on its own refresh loop that could perhaps be configured per plugin or perhaps per document type (e.g. you could configure a tight loop, maybe every 5-10 minutes for entities, but more like hours for docs).  We hadn't considered event-driven index management at all, nor incremental document management.
But I'd love to hear any expectations you have in terms of index execution timing/lifecycle.

Thanks @Fox32!  We were thinking of it living on its own refresh loop that could perhaps be configured per plugin or perhaps per document type (e.g. you could configure a tight loop, maybe every 5-10 minutes for entities, but more like hours for docs).  We hadn't considered event-driven index management at all, nor incremental document management.
But I'd love to hear any expectations you have in terms of index execution timing/lifecycle.

I think there are some reasons not to directly interact with catalog refresh loop as there might be content that is not part of the catalog. Event-driven would be neat: The catalog refresh loop could emit events and techdocs could also emit events once document generation is completed. On the other side, a loop based approach would be useful for techdocs that are published via CI/CD and other content that doesn't have a refresh loop on its own.
Maybe we need both? But starting with an own loop and later evolving to support event driven approached sounds nice.

I think there are some reasons not to directly interact with catalog refresh loop as there might be content that is not part of the catalog. Event-driven would be neat: The catalog refresh loop could emit events and techdocs could also emit events once document generation is completed. On the other side, a loop based approach would be useful for techdocs that are published via CI/CD and other content that doesn't have a refresh loop on its own.
Maybe we need both? But starting with an own loop and later evolving to support event driven approached sounds nice.

Wanna start throwing some ideas around for the data structures and interfaces involved here, or is that a bit early? :grin:
type SearchQuery = ???

type SearchResult = ???

type SearchApi {
  search(query: SearchQuery): Promise<SearchResult>
}

Wanna start throwing some ideas around for the data structures and interfaces involved here, or is that a bit early? :grin:
type SearchQuery = ???

type SearchResult = ???

type SearchApi {
  search(query: SearchQuery): Promise<SearchResult>
}

Search extension: integrations.
It would be nice if, depending on the registered integrations, perhaps search collected from them as well.  For example, if I have a GitHub Enterprise integration, if in the search box I type "python Time", it would be great if maybe:

Low hanging fruit: There was a link on the resulting page to fire that same search into my relevant SCM provider. (Github, GitLab, whatever)
Initial integration: search result metadata from my SCM provider could be returned, something like "We found 74,040 results in GitHub. Click here to search there", and it just took you to the raw provider search results in GitHub.
Perfect world: search results from my SCM provider could be integrated into the Backstage search results.

Now for GItHub.com, searching all of that wouldn't be valuable, so the scoping could be say only orgs you've integrated or something, or let search be configured to either limit scope to org(s) or entire instance.

Search extension: integrations.
It would be nice if, depending on the registered integrations, perhaps search collected from them as well.  For example, if I have a GitHub Enterprise integration, if in the search box I type "python Time", it would be great if maybe:

Low hanging fruit: There was a link on the resulting page to fire that same search into my relevant SCM provider. (Github, GitLab, whatever)
Initial integration: search result metadata from my SCM provider could be returned, something like "We found 74,040 results in GitHub. Click here to search there", and it just took you to the raw provider search results in GitHub.
Perfect world: search results from my SCM provider could be integrated into the Backstage search results.

Now for GItHub.com, searching all of that wouldn't be valuable, so the scoping could be say only orgs you've integrated or something, or let search be configured to either limit scope to org(s) or entire instance.

PS: regarding the roadmap. Notice on the main Backstage roadmap, there's an empty search element without a linkage. This is different than the actual full search roadmap in the search section. So may want to line the two up somehow is all?
https://backstage.io/docs/overview/roadmap#ongoing-work-

PS: regarding the roadmap. Notice on the main Backstage roadmap, there's an empty search element without a linkage. This is different than the actual full search roadmap in the search section. So may want to line the two up somehow is all?
https://backstage.io/docs/overview/roadmap#ongoing-work-

Fantastic idea @adamdmharvey, could even be used for any Q&A tool you have been setting up within your organization and potentially later even integrated to backstage. For example Stack Overflow. To get from stuck to unstuck faster!

Fantastic idea @adamdmharvey, could even be used for any Q&A tool you have been setting up within your organization and potentially later even integrated to backstage. For example Stack Overflow. To get from stuck to unstuck faster!

Big 👍 to the proposed architecture and roadmap 😄
A few observations it might help for us to have recorded ideas on.  For context, my perspective from this comes mostly from integrating datasets in cold-storage into search in the internal Spotify backstage deployment.
My understanding is that there is an emerging opinion that the catalog contains non-ephemeral artifacts, essentially all the entities within the Ecosystem Model.  Search needs often extend beyond this, as is alluded to in conversation here.  Datasets (while they have adjacent components in the form of workflows or queries that produce them) are one such example we have within Spotify, but we also have others like an index of Spotifiers and their IAM/LDAP groups, for which no catalog facing equivalent exists and a separate integration makes more sense.
A nice property of the proposed architecture is that some of the uneven qualities during creation of typed indexes can be configured independently. One example already captured in the proposal is timeliness of updates, by decoupling from the catalog refresh loop as @iamEAP suggests.
A perhaps more complex "uneven" quality is scoring of relevance in the case of search across all indexes.  The fields and importance of them will differ by case. The available query paradigms will also differ across underlying backends (lunr vs elasticsearch, etc).  Github, as suggested in @adamdmharvey's comment, scores results itself independently.
I wonder if we should explicitly push that concern into the underlying search backend in the proposal, or if there's an alternate approach.  Also wonder how important the "search over all" use case is generally speaking.

Big 👍 to the proposed architecture and roadmap 😄
A few observations it might help for us to have recorded ideas on.  For context, my perspective from this comes mostly from integrating datasets in cold-storage into search in the internal Spotify backstage deployment.
My understanding is that there is an emerging opinion that the catalog contains non-ephemeral artifacts, essentially all the entities within the Ecosystem Model.  Search needs often extend beyond this, as is alluded to in conversation here.  Datasets (while they have adjacent components in the form of workflows or queries that produce them) are one such example we have within Spotify, but we also have others like an index of Spotifiers and their IAM/LDAP groups, for which no catalog facing equivalent exists and a separate integration makes more sense.
A nice property of the proposed architecture is that some of the uneven qualities during creation of typed indexes can be configured independently. One example already captured in the proposal is timeliness of updates, by decoupling from the catalog refresh loop as @iamEAP suggests.
A perhaps more complex "uneven" quality is scoring of relevance in the case of search across all indexes.  The fields and importance of them will differ by case. The available query paradigms will also differ across underlying backends (lunr vs elasticsearch, etc).  Github, as suggested in @adamdmharvey's comment, scores results itself independently.
I wonder if we should explicitly push that concern into the underlying search backend in the proposal, or if there's an alternate approach.  Also wonder how important the "search over all" use case is generally speaking.

Oh hey @DeaconDesperado, good to see you!

an index of Spotifiers and their IAM/LDAP groups, for which no catalog facing equivalent exists

Well in the open source catalog, they actually do. :) Optionally.

Also wonder how important the "search over all" use case is generally speaking.

This has been on my mind as well. I think it would be hard to co-arrange results for both catalog entities, free text in docs, enum values from dataset fields, etc etc, meaningfully. I think the most power and specificity may be had when we have a few different "compartments" of search.

Oh hey @DeaconDesperado, good to see you!

an index of Spotifiers and their IAM/LDAP groups, for which no catalog facing equivalent exists

Well in the open source catalog, they actually do. :) Optionally.

Also wonder how important the "search over all" use case is generally speaking.

This has been on my mind as well. I think it would be hard to co-arrange results for both catalog entities, free text in docs, enum values from dataset fields, etc etc, meaningfully. I think the most power and specificity may be had when we have a few different "compartments" of search.

Nice!  I expect I'll have a lot of these moments where my understanding is based on the internal deployment in places we have yet to catch up 😄. Nice to see that's a catalog member now.  It does change some of my understanding as to what we'd rely on the catalog for and what we'd gather into backstage via alternate means (as alluded to in the linked comment from @mbruggmann) though.
Yeah, I think the compartments idea you mention is sort of what I have as a mental visual as well.  If it doesn't trade too greatly on the user experience, it might make sense to just treat each searchable type as a disjoint thing, serviced by similar but separate stacks from the right hand side of the diagram in the architecture proposal.  This would mean basically you allow the underlying index (wherever it's served) to form the best opinion as to what's relevant.  It might mean trading away the ALL category to some extent though.

Nice!  I expect I'll have a lot of these moments where my understanding is based on the internal deployment in places we have yet to catch up 😄. Nice to see that's a catalog member now.  It does change some of my understanding as to what we'd rely on the catalog for and what we'd gather into backstage via alternate means (as alluded to in the linked comment from @mbruggmann) though.
Yeah, I think the compartments idea you mention is sort of what I have as a mental visual as well.  If it doesn't trade too greatly on the user experience, it might make sense to just treat each searchable type as a disjoint thing, serviced by similar but separate stacks from the right hand side of the diagram in the architecture proposal.  This would mean basically you allow the underlying index (wherever it's served) to form the best opinion as to what's relevant.  It might mean trading away the ALL category to some extent though.

Adding some more thoughts/considerations here:

Would it make sense to split the querying from the indexing in the backend? Such that we'd have @backstage/plugin-search-backend and @backstage/plugin-search-indexer? That would make it so other backend plugins can use the indexer without including the querying parts.
For integrating different search engines, those two packages could define an integration API. So a @backstage/plugin-search-elastic plugin could implement an API as described by @Rugvip, and an equivalent one for indexing documents, using an elasticsearch client.
Do you intend to set constraints on what can be indexed? For example, must all indexed content be tied to an entity in the catalog? Or some other known attributes that we could use for faceting? I think that would simplify the setup quite a bit. It would also naturally limit us to indexing content that actually is in Backstage, and not become a general-purpose search engine.
I don't have a strong opinion if the indexing API should be synchronous push or event-based or a refresh loop, but it would help to make that explicit in the design. In any case, I'd try to avoid duplicating things search engines are good at in Backstage, and heavily rely on pushing concerns down to whatever search stack we are using (as pointed out by @DeaconDesperado). What I would add though is some form of structured logs, so we know what queries were issued, what results we served, and what users clicked. That'd be useful for evaluating how well it's working, and as training data in the future should we want to go down the ML path.

Adding some more thoughts/considerations here:

Would it make sense to split the querying from the indexing in the backend? Such that we'd have @backstage/plugin-search-backend and @backstage/plugin-search-indexer? That would make it so other backend plugins can use the indexer without including the querying parts.
For integrating different search engines, those two packages could define an integration API. So a @backstage/plugin-search-elastic plugin could implement an API as described by @Rugvip, and an equivalent one for indexing documents, using an elasticsearch client.
Do you intend to set constraints on what can be indexed? For example, must all indexed content be tied to an entity in the catalog? Or some other known attributes that we could use for faceting? I think that would simplify the setup quite a bit. It would also naturally limit us to indexing content that actually is in Backstage, and not become a general-purpose search engine.
I don't have a strong opinion if the indexing API should be synchronous push or event-based or a refresh loop, but it would help to make that explicit in the design. In any case, I'd try to avoid duplicating things search engines are good at in Backstage, and heavily rely on pushing concerns down to whatever search stack we are using (as pointed out by @DeaconDesperado). What I would add though is some form of structured logs, so we know what queries were issued, what results we served, and what users clicked. That'd be useful for evaluating how well it's working, and as training data in the future should we want to go down the ML path.

Thanks for comments, its all so valuable! Following up on a few things

Wanna start throwing some ideas around for the data structures and interfaces involved here, or is that a bit early? 😁

@Rugvip yes please, the more we can collect and share here the better we will be able to serve different needs.

Would it make sense to split the querying from the indexing in the backend?

@mbruggmann Yes really good point, I think it make sense to split them up. As in the proposed architecture, the only thing other backend plugins need to use is the indexer and then the search engine integration layer(s) will be responsible for compile and construct the queries.

Do you intend to set constraints on what can be indexed?

@mbruggmann This is a really good question and I don't have a very clear answer to this. In a perfect scenario I do not want to set constraints on what can be indexed as I think we do want to cover as many needs as possible and we really want search to be a place where you should be able to get unstuck, if that is to search across stack overflow questions and answers from your internal Stack Overflow within the organization (which are not tied to an entity but maybe a good complement to your internal technical documentation) I believe that should be able to get indexed. To avoid having to take that extra step to another tool, when you maybe spend the rest of your time in Backstage. So with that said, I don't think we should have constraints saying it MUST be tied to an entity. But I do think we need to come up with with what you say "some other know attributes that we could use for faceting". And I'm happy to have more conversations on this specific topic!

Also wonder how important the "search over all" use case is generally speaking.
I think the most power and specificity may be had when we have a few different "compartments" of search.
It might mean trading away the ALL category to some extent though.

@DeaconDesperado @freben really good questions and points. I wonder if that is something that get used just because it exist and that most of us have some sort of clear idea (domain, area, use case) what we are looking for when using search in Backstage. We also do see more and more that we are splitting up the search experiences internally, so TechDocs has its own search, and so on. I know @katz95 and your team have been doing some research here so would be super valuable if you have any input on when there is a need for the "All" search among our users.

Thanks for comments, its all so valuable! Following up on a few things

Wanna start throwing some ideas around for the data structures and interfaces involved here, or is that a bit early? 😁

@Rugvip yes please, the more we can collect and share here the better we will be able to serve different needs.

Would it make sense to split the querying from the indexing in the backend?

@mbruggmann Yes really good point, I think it make sense to split them up. As in the proposed architecture, the only thing other backend plugins need to use is the indexer and then the search engine integration layer(s) will be responsible for compile and construct the queries.

Do you intend to set constraints on what can be indexed?

@mbruggmann This is a really good question and I don't have a very clear answer to this. In a perfect scenario I do not want to set constraints on what can be indexed as I think we do want to cover as many needs as possible and we really want search to be a place where you should be able to get unstuck, if that is to search across stack overflow questions and answers from your internal Stack Overflow within the organization (which are not tied to an entity but maybe a good complement to your internal technical documentation) I believe that should be able to get indexed. To avoid having to take that extra step to another tool, when you maybe spend the rest of your time in Backstage. So with that said, I don't think we should have constraints saying it MUST be tied to an entity. But I do think we need to come up with with what you say "some other know attributes that we could use for faceting". And I'm happy to have more conversations on this specific topic!

Also wonder how important the "search over all" use case is generally speaking.
I think the most power and specificity may be had when we have a few different "compartments" of search.
It might mean trading away the ALL category to some extent though.

@DeaconDesperado @freben really good questions and points. I wonder if that is something that get used just because it exist and that most of us have some sort of clear idea (domain, area, use case) what we are looking for when using search in Backstage. We also do see more and more that we are splitting up the search experiences internally, so TechDocs has its own search, and so on. I know @katz95 and your team have been doing some research here so would be super valuable if you have any input on when there is a need for the "All" search among our users.

Do you intend to set constraints on what can be indexed? For example, must all indexed content be tied to an entity in the catalog? Or some other known attributes that we could use for faceting?

@mbruggmann this is great to think about. My interest in keeping it fairly open-ended is that it may provide a plausible, gentle onramp to migrating non-Backstage tooling into Backstage (e.g. make your tool centrally searchable first, and in the process create a plugin; migrate your tool's functionality / experience into the plugin afterward).
That being said, we may want to encourage some standards by convention.  Perhaps we don't require that the thing you indexed be directly related to an entity but we carve out a well known field/property that represents it, which any type of indexed document could choose to provide.  As well as maybe some required properties to ensure a reasonable default "all" search experience (title, body, location)

What I would add though is some form of structured logs, so we know what queries were issued, what results we served, and what users clicked. That'd be useful for evaluating how well it's working, and as training data in the future should we want to go down the ML path.

@mbruggmann Ooh, data has been top of mind for me as well, as we focused quite a bit of energy on it internally (less for ML and more just for measuring success).  To my knowledge, there is nothing in place yet for analytics/telemetry generally, but the needs are growing.  Honestly worth its own architecture proposal / RFC, TBH.

I think the most power and specificity may be had when we have a few different "compartments" of search.

Digging the discussion in this area too!  I'm thinking the decision to put the primary search page in the App, rather than in a plugin + making the search components composable goes a long way toward enabling this.  Perhaps what we need to do is solidify the manner in which that happens across the wire.
e.g. riffing on @Rugvip's types, you might imagine being able to specify a compartment/context/domain in the frontend...
// User enters "visualization" as their search term
<SearchBar domain="data" />

...Triggers a request with a body like...
{
  "term": "visualization",
  "domain": "data",
  "filters": []
}

Which would end up somewhere like this in the backend...
// This will of course vary from Backstage instance to Backstage instance
// But we'd also want to provide a sane default per supported search engine?
function compileQuery(request: SearchRequest): ExecutableQuery<SomeSearchEngine> {
  switch (request.domain) {
    case 'data':
      return queryBuilder
        .query('match', request.term, [/* ... data-specific fields ... */])
        .addFilter('documentType', 'isIn', [/* ... document types relevant to data people ...*/]);
    default:
      return queryBuilder.query('match', request.term, ['_all']);
  }

Maybe?

Do you intend to set constraints on what can be indexed? For example, must all indexed content be tied to an entity in the catalog? Or some other known attributes that we could use for faceting?

@mbruggmann this is great to think about. My interest in keeping it fairly open-ended is that it may provide a plausible, gentle onramp to migrating non-Backstage tooling into Backstage (e.g. make your tool centrally searchable first, and in the process create a plugin; migrate your tool's functionality / experience into the plugin afterward).
That being said, we may want to encourage some standards by convention.  Perhaps we don't require that the thing you indexed be directly related to an entity but we carve out a well known field/property that represents it, which any type of indexed document could choose to provide.  As well as maybe some required properties to ensure a reasonable default "all" search experience (title, body, location)

What I would add though is some form of structured logs, so we know what queries were issued, what results we served, and what users clicked. That'd be useful for evaluating how well it's working, and as training data in the future should we want to go down the ML path.

@mbruggmann Ooh, data has been top of mind for me as well, as we focused quite a bit of energy on it internally (less for ML and more just for measuring success).  To my knowledge, there is nothing in place yet for analytics/telemetry generally, but the needs are growing.  Honestly worth its own architecture proposal / RFC, TBH.

I think the most power and specificity may be had when we have a few different "compartments" of search.

Digging the discussion in this area too!  I'm thinking the decision to put the primary search page in the App, rather than in a plugin + making the search components composable goes a long way toward enabling this.  Perhaps what we need to do is solidify the manner in which that happens across the wire.
e.g. riffing on @Rugvip's types, you might imagine being able to specify a compartment/context/domain in the frontend...
// User enters "visualization" as their search term
<SearchBar domain="data" />

...Triggers a request with a body like...
{
  "term": "visualization",
  "domain": "data",
  "filters": []
}

Which would end up somewhere like this in the backend...
// This will of course vary from Backstage instance to Backstage instance
// But we'd also want to provide a sane default per supported search engine?
function compileQuery(request: SearchRequest): ExecutableQuery<SomeSearchEngine> {
  switch (request.domain) {
    case 'data':
      return queryBuilder
        .query('match', request.term, [/* ... data-specific fields ... */])
        .addFilter('documentType', 'isIn', [/* ... document types relevant to data people ...*/]);
    default:
      return queryBuilder.query('match', request.term, ['_all']);
  }

Maybe?

Hey all, thank you so much for all valuable feedback. We have now looked through all of it and will make some changes to the architecture as well as start the work towards the next version of the search experience in Backstage. You can keep track of any updates or the next steps in the Roadmap as well as keep your eyes open for milestones and issues we will create in the upcoming week(s).


minimum-stability issues

When running
$ composer global require humbug/box:^3.0@dev

I receive the following error
$ composer global require humbug/box:^3.0@dev
Changed current directory to /home/ojrask/.config/composer
./composer.json has been created
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - humbug/box 3.x-dev requires composer/xdebug-handler dev-master -> satisfiable by composer/xdebug-handler[dev-master] but these conflict with your requirements or minimum-stability.
    - humbug/box 3.0.0-alpha.1 requires composer/xdebug-handler dev-master -> satisfiable by composer/xdebug-handler[dev-master] but these conflict with your requirements or minimum-stability.
    - humbug/box 3.0.0-alpha.0 requires humbug/php-scoper ^1.0@dev -> satisfiable by humbug/php-scoper[1.0.x-dev] but these conflict with your requirements or minimum-stability.
    - Installation request for humbug/box ^3.0@dev -> satisfiable by humbug/box[3.0.0-alpha.0, 3.0.0-alpha.1, 3.x-dev].

Installation failed, deleting ./composer.json.

Running on Composer 1.6.4 and PHP 7.2.4.
This can be resolved by adding proper stability requirements to my global composer.json, yes? Would a note about dev stability be appropriate in installation instructions?

Good catch! I would rather update composer/xdebug-handler since a new released has been tagged :)

Okay, would this happen soonish? Will alter my CI pipeline config in the meantime. Thanks!  :)

Maybe tonight unless you go ahead and do a PR :)

I see you updated it, will try it out soon. Thanks!


Rename Signal.Connect parameter

Closes #793

Hi thanks for the PR :+1: . Can you squash your two commits into one?

Can you squash your two commits into one?

done :)

Hm I just thought about the name a bit more. The generic argument is named TSender perhaps the parameter should be called sender instead of obj?


min/max limitation setting of volume&scatter plots

min/max limitation setting for both volume and scatter plots doesn't work correctly. The Visual outside the gridbox should not be shown.

We should set_data(cutted_array) to each visual on _update_limits() in vispy_widget.py, now there is only setting for the transform of each visual.

Right, it was actually intentional to leave the visual outside the box originally but I think maybe it does make sense to hide stuff outside the box otherwise it can be confusing. The same applies for the scatter plots.

This is the same issue as https://github.com/glue-viz/glue-vispy-viewers/issues/175

Done in #203


Undefined error upon opening Connection Dialog

Azure Data Studio Version: 1.42.0-Insiders
OS Version: MacOS

Steps to Reproduce:

Open ADS
Open the Connection Dialog
Error is thrown in the Dev Tools Console:

Upon initial investigation, it seems like the culprit might be this._initialConnectionInfo.authenticationType = AuthenticationType.SqlLogin; (line 673 in connectionWidget.ts), introduced here: #21813
@lewis-sanchez do you think you could take a look?

@cssuh, yes looking now.

@cssuh, does your branch have the latest from main? I'm not able to see that error when I connect to accounts.


Option to Ignore Reblogs?

Hello, I am new here but I am trying to download a whole list of original art blogs. However, some of these art blogs contain thousands of reblogs that are also downloaded which increases download times and space used on my PC. Is there an option to ignore reblogs and to only download original posts?

Duplicate of #8.

I'll add that later today. I've already checked the data, shouldn't be more than a few lines of code.

Man, thank you so much, some blogs have like 30000 plus reblogs with a few hundred original posts. This will help trim that down and save so much time.


Add option for Align on Layout component

As I was working with this library one of the features that I felt I needed was the ability to vertically align items. Right now the only component I saw that implements flex-direction: column is Layout however there is not an option to pass align like with the Grid. I was able to get this to work by manually passing a style but I think it would be good to make the Layout and Grid components more consistent.

Closing since we'll be removing Layout on the next version


Free inodes not reported correctly / always zero

First of all, congrats on an awesome piece of kit! Is very useful already.
I'm trying to get a volume using this storage driver working using a tool called Minio so that I can circumvent the limitations using AzureFS on Linux (no SMB3 support, poor tooling around syncing full directories of files in Linux).  However, the free inodes reported by this driver are always zero, which causes issues in Minio (reports no free space).
Example would be similar to this (doctored):

$ docker volume create --name my_volume -d azurefile -o share=myshare
$ docker run -i -t -v my_volume:/data busybox
$ df -h /data
$ Filesystem                                                   Size  Used Avail Use% Mounted on
$ //example.file.core.windows.net/myshare   10G   36M   10G   1% /data
$ df -i /data
$ Filesystem                                                  Inodes IUsed IFree IUse% Mounted on
$ //example.file.core.windows.net/myshare      0     0     0     - /data

Is this perhaps an issue with the underlying CIFS driver, or perhaps even Unix support on the Azure FS SMB shares?  I'd imagine this will cause issues with other software checking the free inodes also.
FYI - similar issue on Minio:
minio server fails to start over CephFS storage directory

@gjonespf Glad you found this plugin useful!
It appears like this might be a SMB protocol or CIFS driver issue. I highly doubt this falls is caused by the docker plugin. Can you please try mounting the Azure File Storage share manually yourself? Instructions are here: https://azure.microsoft.com/en-us/documentation/articles/storage-how-to-use-files-linux/

Hey @ahmetalpbalkan , yup can definitely confirm same issues (zero available inodes) mounting using instructions on that web page.  I should have thought of trying that.  So either an issue in the CIFS kernel driver/user drivers or perhaps Azure FS mounts not supporting the Unix extensions.
Thanks for the prompt response!

@gjonespf please feel free to raise this issue in the comments section on the link above. I'm sure the Storage folks on Azure side would be interested.


Fix Typo and link issues

Describe your changes :

fix #9736

Type of change :

[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[x] Documentation

Frontend Preview (Screenshots) :
For frontend related change, please link screenshots of your changes preview! Optional for backend related changes.

Checklist:

[x] I have read the CONTRIBUTING document.
[ ] I have commented on my code, particularly in hard-to-understand areas.
[ ] I have added tests that prove my fix is effective or that my feature works.
[x] All new and existing tests passed.

Reviewers

Merging this as the checks failed and not related to this PR


Upgrade Astro to 2.10.5

What kind of changes does this PR include?

Something else!

Description

Bumps Astro to v2.10.5

size-limit report 📦

Path
Size

/index.html
9.52 KB (+0.4% 🔺)

/_astro/*.js
16.33 KB (+3.02% 🔺)

/_astro/*.css
8.39 KB (0%)


osu-lazer{-bin,}: 2023.1224.0 -> 2023.1229.0

Description of changes
Changelog: https://github.com/ppy/osu/releases/tag/2023.1229.0
Diff: https://github.com/ppy/osu/compare/2023.1224.0...2023.1229.0

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 277401 run on x86_64-linux 1

2 packages built:

osu-lazer
osu-lazer-bin


[UNBOUND DNS] QWANT search KO with Safesearch enabled

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

[x] I have read the contributing guide lines at https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md
[x] I have searched the existing issues, open and closed, and I'm convinced that mine is new.
[x] The title contains the plugin to which this issue belongs

Describe the bug
When Safesearch is enabled in the UNBOUND DNS plugin in the Blocklist function, QWANT search return a JSON request instead of search content.

If everything would works, we should have a list related to our search

Move this issue to CORE as it is a part of it


Ceph metrics and monitoring

They have a jsonnet mixin for monitoring:
https://github.com/ceph/ceph/tree/main/monitoring/ceph-mixin
Rook also provides examples for the ServiceMonitor CRs to configure:
https://github.com/rook/rook/tree/master/deploy/examples/monitoring

https://github.com/JacksonWrath/k8s-config-weebcluster/commit/6fb4989ac3f8c3eb66b58fac6d932bf1a62caa75
plus follow ups
https://github.com/JacksonWrath/k8s-config-weebcluster/commit/06fa24d6695ea3838b5d8af8c8c93ee4da4423c8
https://github.com/JacksonWrath/k8s-config-weebcluster/commit/d7911f6bee2eadd88b73e60ff0b7dd5162afcca8
One thing of note is they're using a really old version of Grafonnet. Has the potential to break in a future Grafana release.


Create list of curriculum for new site (content)

As a companion to https://github.com/girldevelopit/gdi-new-site/issues/66, create a list of curriculum for the new site. Each needs:

Title
Icon (from http://mfizz.com/oss/font-mfizz for now)
Long description
Short description
Links to slides on git pages
Links to practice files and homework (optional)
Link to GitHub repo

I've got a large collection of svg icons for all the techs - just curious which one's were going to have on the page. Do you have a list started so I can start plugging away at the icons?

you can always upload the icons for the class in the admin side

@Cara-Jo Minimum list:
Introduction to Web Concepts
Web Accessibility
Intro to Git and Github
Introduction to HTML/CSS
Intermediate HTML/CSS
Introduction to JavaScript
Introduction to jQuery
Hoping to get the Python and WordPress libraries cleaned up and posted as well, but it may be a few days post-launch. I have some simple PNGs for everything if needed, but more beautiful options are always appreciated. They need to be actual image files to work with the current active admin interface. We can talk about adding a way to icon-ify them in a future release.

Yeah I just want to have the icons available for people to upload. :) Thanks for the list!

Here's a folder with a bunch of icons in SVG and then exported in the navy color in .PNG format: https://www.dropbox.com/s/h008rmsup2x6r5r/materials-icons.zip?dl=0
@Roenok I can also e-mail this to you if it doesn't work for you. Excuse my poor artboard layout on materials.ai :P

@Roenok checking in to see how the progress is moving along for this one. Do you need any help with anything?

@juliaelman Core stuff is in, so we can probably close. Some other stuff is pending review, not ready to post.

@Roenok cool! I close. :tada: Thank you!


Add core dependencies installation script

This PR adds a script to pull and install all core dependencies needed for the LaMAR.
Warning, the C++ dependencies will be installed system wide.
This PR also:

downgrades the version of pycolmap for compatibility issues with COLMAP 3.8.
downgrades the numpy version in scantools for compatibility with the numpy version of LaMAR.
adds dependency for scikit-learn because HLOC 1.4 requires it.
update Dockerfile.

@microsoft-github-policy-service agree

Thanks a lot for the contribution @ovysotska !
The docker image is not fully functional either as some calls to pycolmap in this pipeline are not compatible with 0.6.0.
That package should be downgraded in any case (or someone should make a full run over the pipeline to fix all the compatibility issues with 0.6.0).
I think it's better if users can also install from scratch without needing docker so having a dedicated script for local setup would be a good thing.

@pablospe thanks for the comment.
I checked the docker/scripts you recommend. They seems to provide instructions to installing hloc and dev dependencies.
In this PR, I am proposing to install the 'core dependencies' such that pcd meshing and raybender are not the part of the script. So hopefully, addressing your concerns here.
About the docker image, yes I tried buidling it. The building part seemed to work :) at least there were no obvious errors.
Unfortunately, I don't know what to do next with it. The readme doesn't tell how to use this image to run laMAR :cry:
I tried creating  a container with this image, however, it just did nothing.
If you could add some instructions how to use that image, that would be great :smile: and I could try that out too.
Thanks!

In this PR, I am proposing to install the 'core dependencies' such that pcd meshing and raybender are not the part of the script.

Ok, I see. Anyways I would like to split this script in several scripts that could be reusable also in the Dockerfile. I will do/propose some changes to this PR, but essentially the same code. Thanks for the contribution!

I will try but now I have a question. Do I need to create my own virtual environment, for example through venv before calling .install_core_dependencies.sh script?

I will try but now I have a question. Do I need to create my own virtual environment, for example through venv before calling .install_core_dependencies.sh script?

Yes, if you want to install the python packages in a new environment. Otherwise, it will install them in the user's default one.

.install_core_dependencies.sh script

Notice that now all the bash scripts are in scripts/ folder. Then, scripts/install_core_dependencies.sh for running it.

I believe it should be ready for merging.

thanks for your work. Is there something I could do about this PR?

Thanks, Olga. I will merge it when it passes the CI checks.


Fix registration of flows and sources on redeploy.

Redeploying a flow to a running server causes errors to be reported about flows and sources, although the registrations seems to work. Older flows and sources are not removed and it may be the update of the device that is causing the issues?

Not observed in recent testing, probably due to move to using promises in registration and discovery. Closing. Will re-open if this is still an issue.


Wrap non-string input to substring function

Hive substr/substring function allows user to input either a String or byte array, but Calcite's substring function only allows String input.
describe string_timestamp_table;
+--------------+------------+----------+
|   col_name   | data_type  | comment  |
+--------------+------------+----------+
| a_string     | string     |          |
| a_timestamp  | timestamp  |          |
+--------------+------------+----------+

select substr(string_timestamp_table.a_timestamp, 12, 8) as newtime from default.string_timestamp_table;
+-----------+
|  newtime  |
+-----------+
| 22:54:24  |
| 22:54:54  |
+-----------+

One way we could try to emulate this behavior would be to attempt to wrap any non-String input in substr/substring function to String type. This might be a bit funky since we need to remove the mapping to Calcite's substring and instead register it as a UDF. Additionally this fix only works for 'substr' but not 'substring', since Calcite will actually override the UDF.
Open to suggestions if there are better approaches to this.

Something happened to my feature branch and now the diff is wonky
Going to re-make the PR

https://github.com/linkedin/coral/pull/190


Won't work on mobile safari

When visiting the send-emotion demo on Mobile Safari. I get the following error:
TypeError: navigator.webkitGetUserMedia is not a function.

A search on caniuse shows that neither Safari nor Mobile Safari support WebRTC so far. Is there an alternative to WebRTC to read audio input?

Unfortunately no.
On Wed, Nov 4, 2015 at 7:55 AM Oscar Tong<EMAIL_ADDRESS>wrote:

When visiting the send-emotion
http://borismus.github.io/sonicnet.js/emoticons/ demo on Mobile Safari.
I get the following error:
TypeError: navigator.webkitGetUserMedia is not a function.
A search on caniuse http://caniuse.com/#search=webrtc shows that
neither Safari nor Mobile Safari support WebRTC so far. Is there an
alternative to WebRTC to read audio input?
—
Reply to this email directly or view it on GitHub
https://github.com/borismus/sonicnet.js/issues/20.


Typescript support

Hey,
I looked through code and saw that the documentation is already really good. But it could be easier to work with if it had Typescript support. Did you ever think about doing something like this?
For me it is a lot easier to work with, because my IDE tells me what functions are there and the documentation of the code. This could make it easier especially for people who are new to lower the bar for them.
I started using your codebase and was working with the documentation. This is also valid and should be sustained, but TS is easier to work with then JS, because with the compile errors you avoid doing a lot of mistakes.

That is not on the list, but if Typescript is backwards compatible with older versions of node (currently supporting >=12), then you are welcome to submit a pull request for it.

Can't we use compilation tools like webpack or rollup or typescript to downgrade the generated code to support es5?
It should be possible to support typescript in this way.
Https://www.typescriptlang.org/tsconfig#target

Adding Typescript is not something I have the bandwidth for in the foreseeable future. Happy to review and potentially merge it in if someone else wants to do it.


Incorrect regex matching when querying using Prometheus 2

What did you do?
I ran the query container_cpu_system_seconds_total{container_name=~"prometheus.*"}
What did you expect to see?
I expected results with container_name="prometheus" AND container_name="prometheus2"
What did you see instead? Under which circumstances?
I have 2 Prometheus servers running side by side, monitoring the same targets. (Reproducing/Tracking @fabxc metrics listed in https://fabxc.org/blog/2017-04-10-writing-a-tsdb/)
My 1.5.2 server returns the expected (multiple) results. (6 in this case) but the v2.0.0-alpha.0 is only returning 4 of the values. It doesn't match against prometheus or prometheus2, but it does match against prometheus-load1, prometheus-dev3, etc.
I verified that the missing ones are present and can filter against them directly with queries like container_name=~"prometheus" (when I leave .* off the end)
Environment
Prometheus v2.0.0-alpha.0 running on Kubernetes 1.5

System information:

Linux 4.4.0-53-generic x86_64

Prometheus version:

prometheus, version 2.0.0-alpha.0 (branch: master, revision: ece483c0c1f2ad11e7dc749ea958669b0914c1c3)
  build user:       root@cd2fcfcce982
  build date:       20170410-11:14:31
  go version:       go1.8

Hmm, this is a little weird. So I am running the dev-2.0 branch and have two jobs prometheus and prometheus2, both scraping the Prometheus server itself. When I run {job=~"prometheus.*"}, both of them show up.
We don't handle lookups on job separately, so I think Prometheus is matching the container_name to prometheus too but for some reason (staleness?) it is not returning the values. @checketts Can you run a range query and see if you are still missing the values?

@Gouthamve Sorry for the delay, I was traveling. The data is coming from the Kubernetes service discovery which means it is collecting the data from each target. I verified that each target is getting scraped within 30 seconds (my scrape rate).  I haven't set a staleness parameter, so I assume the default staleness of 5 minutes should be used.
I ran the range query below and it behaved completely identical to when I left increase off.
increase(container_cpu_system_seconds_total{container_name=~"prometheus"}[5m])
Some more query datapoints:
container_name=~"prometheus|prometheus2" Returns 2 of the 6 results (prometheus and prometheus2)
But container_name=~"prometheus|prometheus2|prometheus.*" returns 2 other results ('prometheus-rigandprometheus2-rig`)
One last datapoint: container_name=~"prometheus|prometheus2|prometheus-rig" Return 3 results (the ones that match identically the names listed. But if I add in one more manually like so: container_name=~"prometheus|prometheus2|prometheus-rig|prometheus2-rig" (note I just add on the prometheus2-rig in the OR). Then results leave out the 'prometheus' one and keep the other 3. It changes based how I order the OR clause.

Regexp matching must be broken is some basic way.
I just tried node_network_transmit_bytes{job="node", device!~"bond[0-9]|cbr[0-9]|veth.*"}, resulting in far fewer results than I expected.
If I query node_network_transmit_bytes{job="node", device="eth3"}, I get loads of results, each of which should also be returned by the query above, but none does.

It's not just regexp matching but any non-equal matcher potentially. My my debugging, the matching itself works correctly but the final postings list of series IDs is missing some.
Most likely it is mergePostings.Seek that advances the underlying postings too far sometimes and causes skipping some entries.
Seek is called when the postings intersections wants to advance an underlying merge postings to a certain value or higher. If I just completely expand a merge postings and intersect that result instead (so the non-lazy way), everything works fine as it seems.

I'm currently testing v2 by letting it to the same thing as a number of our v1 servers. However, because of this bug, I cannot really compare the results: Many rules don't give the same result, and most dashboards are half-empty because of this.

@fabxc can we get https://github.com/prometheus/tsdb/pull/77 vendored into dev-2.0. Would love to try it out :)

I also would be eager to get a new beta build that I can hammer and report on.

@checketts we'll probably wait just a bit more because. Some TODOs left before alpha.1.
However, you can build from the dev-2.0 branch, which basically reflects whatever would go into the next alpha as well.

Would checking out the dev-2.0 branch and running make docker be sufficient? (I apologize I'm still pretty new to Go)

make promu; CGO_ENABLED=0 promu build; make docker would do it after checking out dev-2.0.
But @fabxc used to have latest dev-2.0 images pushed to Quay somewhere, not able to find the link now.

Yea, basically this. If not on Linux addtionally GOOS=linux must be set.
GOOS=linux make build && make docker should work.

I think this can be closed. Are you still seeing some lost series?

@Gouthamve Yes, in my case you can close it. Not certain about @beorn7 case though

I think we have pretty clearly identified the source of this and fixed it.


Clarify how to add images to RSS

📚 Subject area/topic
RSS
📋 Page(s) affected (or suggested, for new content)
https://docs.astro.build/en/guides/rss/
📋 Description of content that is out-of-date or incorrect
Following the guide for adding an RSS feed, you'll be left with an RSS feed with no images.
Explaining how to add this with sanitize-html would be good.
I've forked and added this here, until I read that I should open an issue for something more than a typo.
Happy to open a PR with my fork too.
🖥 Reproduction in StackBlitz (if reporting incorrect content or code samples)
No response

@at-the-vr Is it ok to open a PR for my fork?

I gotta ask if you could wait for approval from maintainers 🙏

Hi @tommyp , this looks like a great idea to add to the RSS content! Thank you for suggesting it!
Thank you for also waiting for the discussion here, and I do have thoughts...
Since we try to keep things concise and simple for everyone, what would you think about working this into the main example itself? So, no second code sample, but add everything required to the original code sample?
So, assume someone did want to include images. What all is required to add to that snippet, and what does the whole thing look like?
The line could be adjusted to something like:

When using content collections, render the post body using a standard Markdown parser like markdown-it and sanitize the result, including any extra tags (e.g. <img>) needed to render your content:

Would be happy to receive a PR along those lines, and we can work out the fine details in the PR itself!  :raised_hands:

I am happy to take a look at implementing this. Since @tommyp already has a fork that does some of the work, if he gets a PR in will let him take it :)!

@sarah11918 Thanks for the suggestion and the vote of confidence @SatanshuMishra! I've opened the PR. Glad I could make a contribution to such an awesome project.


Added 'angle' property for DisplayObject

The proposed solution from https://github.com/pixijs/pixi.js/pull/4579 which got recently closed.
I've had angle as a property like this on my version of PIXI for a while, and it makes it so much easier to configure a display object's rotation via JSON :)

Might be nice to add a simple unit test or two. To validate the API

@bigtimebuddy done!


ERROR: Cannot set headers after they are sent to the client                                                                                :   Cannot set headers after they are sent to the client

Hello I made nuxt-nitro demo clone  without nitro. URL is here. https://nuxt-without-nitro-demo.vercel.app/
I try with /api/hello made with h3, It failed after deploy. When I test on local, It make error.
 ERROR  Cannot set headers after they are sent to the client                                                                                20:39:12

  at ServerResponse.setHeader (_http_outgoing.js:518:11)
  at sendError (node_modules/h3/dist/index.js:502:7)
  at node_modules/h3/dist/index.js:514:14

My server middleware is  https://github.com/ChangJoo-Park/nuxt-without-nitro-demo/blob/main/server/hello.js#L4-L8.
I tested with remove res.setHeader('Access-Control-Allow-Origin', '*') . but it fails too.

This issue caused by ky-universal in nuxt/http module. not h3's fault.

Reopen, It failed with axios with h3. but axios with express deploy success on vercel.
Here is full error logs.
2021-03-16T12:30:43.457Z	65954691-80e8-4140-ab8c-c93745ae5689	ERROR	Unhandled Promise Rejection 	{"errorType":"Runtime.UnhandledPromiseRejection","errorMessage":"Error [ERR_HTTP_HEADERS_SENT]: Cannot set headers after they are sent to the client","reason":{"errorType":"Error","errorMessage":"Cannot set headers after they are sent to the client","code":"ERR_HTTP_HEADERS_SENT","stack":["Error [ERR_HTTP_HEADERS_SENT]: Cannot set headers after they are sent to the client","    at ServerResponse.setHeader (_http_outgoing.js:558:11)","    at sendError (/var/task/node_modules/h3/dist/index.js:502:7)","    at /var/task/node_modules/h3/dist/index.js:514:14"]},"promise":{},"stack":["Runtime.UnhandledPromiseRejection: Error [ERR_HTTP_HEADERS_SENT]: Cannot set headers after they are sent to the client","    at process.<anonymous> (/var/runtime/index.js:35:15)","    at process.emit (events.js:327:22)","    at processEmit [as emit] (/var/task/node_modules/signal-exit/index.js:161:32)","    at processPromiseRejections (internal/process/promises.js:245:33)","    at processTicksAndRejections (internal/process/task_queues.js:94:32)"]}
Unknown application error occurred

@ChangJoo-Park Thank you so much for your contributions - PRs and issues! ❤
Could you create a reproduction without Nuxt? (Or alternatively, raise this as an issue in the nuxt repo if it's specific to Nuxt?)

Thank you for reply, @danielroe !
I'll make repo without Nuxt.

Here you are. https://github.com/ChangJoo-Park/h3-issue-21/
It is not happen. It seems to have occurred because of h3 on Nuxt.

Same issue as well

Also getting this error systematically when trying to implement server-sent events in a fresh Nuxt3 project.

Just started getting his error too. Fresh project.
ERROR  [unhandledRejection] Cannot set headers after they are sent to the client                             21:36:35
at new NodeError (node:internal/errors:372:5)
at ServerResponse.setHeader (node:_http_outgoing:576:11)
at sendError (/C:/Users/tobychidi/Documents/GitHub/CodeKing/codeking-nuxt/node_modules/.pnpm/h3@0.7.13/node_modules/h3/dist/index.mjs:233:13)
at nodeHandler (/C:/Users/tobychidi/Documents/GitHub/CodeKing/codeking-nuxt/node_modules/.pnpm/h3@0.7.13/node_modules/h3/dist/index.mjs:396:15)

There might be several usage issues that call a utility from h3 after headers are sent. If you think it might be a bug with h3, please share a reproduction 🙏🏼


Kusion Module support other DSLs (cuelang, Pkl e.g.)

For now, Kusion Module only support KCL for schema definition, but actually Kusion Module is not bound to KCL, we can support other kinds of Domain Specific Language, such as cuelang or Pkl, and this can bring much more flexibility for developers.

2025 Q1