Running --tests with multiple --tests parameters does not work as expected

Note
Before you submit your issue, make sure that:

[x] > - You're using the latest version of Salesforce CLI.
[x] > - You've searched both open and closed issues for related posts.
[ ] > - You've used the doctor command to diagnose common issues.
[x] > - You understand that GitHub Issues don't adhere to any agreement or SLA.
[x] >   - If you require immediate assistance, use official channels such as Salesforce Customer Support.

Context
Executed within Github Actions

Image: ubuntu-22.04
Version: 20240414.1.0

  npm install -g @salesforce/cli
  sf version --verbose --json

{
  "architecture": "linux-x64",
  "cliVersion"<EMAIL_ADDRESS>  "nodeVersion": "node-v18.20.2",
  "osVersion": "Linux 6.5.0-1018-azure",
  "rootPath": "/usr/local/lib/node_modules/@salesforce/cli",
  "shell": "bash",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.0.13 (core)",
    "@oclif/plugin-commands 3.2.2 (core)",
    "@oclif/plugin-help 6.0.20 (core)",
    "@oclif/plugin-not-found 3.1.2 (core)",
    "@oclif/plugin-plugins 5.0.7 (core)",
    "@oclif/plugin-search 1.0.20 (core)",
    "@oclif/plugin-update 4.2.4 (core)",
    "@oclif/plugin-version 2.0.16 (core)",
    "@oclif/plugin-warn-if-update-available 3.0.15 (core)",
    "@oclif/plugin-which 3.1.7 (core)",
    "@salesforce/cli 2.37.4 (core)",
    "apex 3.1.4 (core)",
    "auth 3.5.5 (core)",
    "data 3.2.5 (core)",
    "deploy-retrieve 3.5.6 (core)",
    "info 3.1.3 (core)",
    "limits 3.2.1 (core)",
    "marketplace 1.1.1 (core)",
    "org 4.0.4 (core)",
    "packaging 2.3.0 (core)",
    "schema 3.2.1 (core)",
    "settings 2.1.2 (core)",
    "sobject 1.2.2 (core)",
    "source 3.2.3 (core)",
    "telemetry 3.1.18 (core)",
    "templates 56.1.1 (core)",
    "trust 3.5.4 (core)",
    "user 3.4.3 (core)"
  ]
}

Summary
The following command works on the development machine
Command:
sf project deploy start --wait 30 --dry-run --verbose --test-level RunSpecifiedTests --tests TriggerHandlerTest --tests ToolkitTest -o<EMAIL_ADDRESS>--manifest package/package.xml --post-destructive-changes destructiveChanges/destructiveChanges.xml

but fails to work in a Github action using Ubuntu. The whole action is a big bash file.
Result
Error (2): Nonexistent flags: --tests TriggerHandlerTest, --tests ToolkitTest
See more help with --help

Steps To Reproduce
sf version --verbose --json

{
  "architecture": "darwin-arm64",
  "cliVersion"<EMAIL_ADDRESS>  "nodeVersion": "node-v20.9.0",
  "osVersion": "Darwin 23.4.0",
  "rootPath": "/usr/local/lib/node_modules/@salesforce/cli",
  "shell": "zsh",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 2.3.10 (core)",
    "@oclif/plugin-commands 3.0.4 (core)",
    "@oclif/plugin-help 6.0.4 (core)",
    "@oclif/plugin-not-found 3.0.2 (core)",
    "@oclif/plugin-plugins 3.9.4 (core)",
    "@oclif/plugin-search 1.0.4 (core)",
    "@oclif/plugin-update 4.1.3 (core)",
    "@oclif/plugin-version 2.0.3 (core)",
    "@oclif/plugin-warn-if-update-available 3.0.2 (core)",
    "@oclif/plugin-which 3.0.6 (core)",
    "@salesforce/cli 2.15.9 (core)",
    "apex 2.3.20 (core)",
    "auth 2.8.25 (core)",
    "custom-metadata 2.2.10 (user)",
    "data 2.6.1 (core)",
    "deploy-retrieve 1.19.2 (core)",
    "dev 1.3.0 (user)",
    "info 2.6.51 (core)",
    "limits 2.3.41 (core)",
    "login 1.2.39 (core)",
    "marketplace 0.3.1 (core)",
    "org 2.11.5 (core)",
    "schema 2.3.31 (core)",
    "settings 1.4.36 (core)",
    "sobject 0.2.14 (core)",
    "source 2.10.45 (core)",
    "telemetry 2.3.8 (core)",
    "templates 55.5.17 (core)",
    "trust 2.6.22 (core)",
    "user 2.3.39 (core)",
    "@salesforce/sfdx-scanner 3.17.0 (user)",
    "sfdmu 4.33.7 (user)",
    "sfdx-git-delta 5.31.1 (user)",
    "skuid-sfdx 0.4.0 (user)"
  ]
}

but it does not work under Github actions that are running under Ubuntu. The result in Ubuntu is:
Result
Error (2): Nonexistent flags: --tests TriggerHandlerTest, --tests ToolkitTest
See more help with --help

Executing the command with one single tag and tests separated by comma, generates a different issue:
Command:
sf project deploy start --wait 30 --dry-run --verbose --test-level RunSpecifiedTests --tests TriggerHandlerTest, ToolkitTest -o<EMAIL_ADDRESS>--manifest package/package.xml --post-destructive-changes destructiveChanges/destructiveChanges.xml

Result
(node:4517) Warning: The previous version of this command used a comma-separated list for tests. We've changed how you specify multiple tests, so if you continue using your current syntax, your tests will probably not run as you expect.

If a test name contains a space, enclose it in double quotes.
For multiple test names, use one of the following formats:

- Repeat the flag for multiple test names: --tests Test1 --tests Test2 --tests "Test With Space"
- Separate the test names with spaces: --tests Test1 Test2 "Test With Space"
(Use `node --trace-warnings ...` to show where the warning was created)
Warning: The previous version of this command used a comma-separated list for tests. We've changed how you specify multiple tests, so if you continue using your current syntax, your tests will probably not run as you expect.

If a test name contains a space, enclose it in double quotes.
For multiple test names, use one of the following formats:

- Repeat the flag for multiple test names: --tests Test1 --tests Test2 --tests "Test With Space"
- Separate the test names with spaces: --tests Test1 Test2 "Test With Space"
Deploying (dry-run) v58.0 metadata to<EMAIL_ADDRESS>using the v60.0 SOAP API.
Deploy ID: 0AfPk000000TXobKAG
Status: {status} | 0/0 Components{errorInfo}{testInfo}{trackingInfo}
Status: In Progress | 0/24 Components
Status: In Progress | 0/24 Components
Status: In Progress | 0/24 Components
Status: In Progress | 15/24 Components
Status: In Progress | 17/24 Components
Status: In Progress | 20/24 Components
Status: In Progress | 20/24 Components

...

Test Results Summary
Passing: 0
Failing: 0
Total: 0
 ›   Warning: Toolkit - Test coverage of selected Apex
 ›   Class is 0%, at least 75% test coverage is required
Time: 6
 ›   Warning: TriggerHandler - Test coverage of selected
 ›   Apex Class is 0%, at least 75% test coverage is required
Dry-run complete.

Expected result

Apex Code Coverage
 Name                              % Covered Uncovered Lines
 ───────────────────────────────── ───────── ─────────────────────────────────────────────────────
 TriggerHandler 88%       81,89,114,115,165,182,183,184,186,187,259,261,278,279
 Toolkit    100%

Test Results Summary
Passing: 3
Failing: 0
Total: 3
Time: 16820

Actual result
Result
Error (2): Nonexistent flags: --tests TriggerHandlerTest, --tests ToolkitTest
See more help with --help

System Information

zsh on local environtment
bash on Github Actions

Local Environment
{
  "architecture": "darwin-arm64",
  "cliVersion"<EMAIL_ADDRESS>  "nodeVersion": "node-v20.9.0",
  "osVersion": "Darwin 23.4.0",
  "rootPath": "/usr/local/lib/node_modules/@salesforce/cli",
  "shell": "zsh",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 2.3.10 (core)",
    "@oclif/plugin-commands 3.0.4 (core)",
    "@oclif/plugin-help 6.0.4 (core)",
    "@oclif/plugin-not-found 3.0.2 (core)",
    "@oclif/plugin-plugins 3.9.4 (core)",
    "@oclif/plugin-search 1.0.4 (core)",
    "@oclif/plugin-update 4.1.3 (core)",
    "@oclif/plugin-version 2.0.3 (core)",
    "@oclif/plugin-warn-if-update-available 3.0.2 (core)",
    "@oclif/plugin-which 3.0.6 (core)",
    "@salesforce/cli 2.15.9 (core)",
    "apex 2.3.20 (core)",
    "auth 2.8.25 (core)",
    "custom-metadata 2.2.10 (user)",
    "data 2.6.1 (core)",
    "deploy-retrieve 1.19.2 (core)",
    "dev 1.3.0 (user)",
    "info 2.6.51 (core)",
    "limits 2.3.41 (core)",
    "login 1.2.39 (core)",
    "marketplace 0.3.1 (core)",
    "org 2.11.5 (core)",
    "schema 2.3.31 (core)",
    "settings 1.4.36 (core)",
    "sobject 0.2.14 (core)",
    "source 2.10.45 (core)",
    "telemetry 2.3.8 (core)",
    "templates 55.5.17 (core)",
    "trust 2.6.22 (core)",
    "user 2.3.39 (core)",
    "@salesforce/sfdx-scanner 3.17.0 (user)",
    "sfdmu 4.33.7 (user)",
    "sfdx-git-delta 5.31.1 (user)",
    "skuid-sfdx 0.4.0 (user)"
  ]
}

Github Action Environment (ERROR environment)
{
  "architecture": "linux-x64",
  "cliVersion"<EMAIL_ADDRESS>  "nodeVersion": "node-v18.20.2",
  "osVersion": "Linux 6.5.0-1018-azure",
  "rootPath": "/usr/local/lib/node_modules/@salesforce/cli",
  "shell": "bash",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.0.13 (core)",
    "@oclif/plugin-commands 3.2.2 (core)",
    "@oclif/plugin-help 6.0.20 (core)",
    "@oclif/plugin-not-found 3.1.2 (core)",
    "@oclif/plugin-plugins 5.0.7 (core)",
    "@oclif/plugin-search 1.0.20 (core)",
    "@oclif/plugin-update 4.2.4 (core)",
    "@oclif/plugin-version 2.0.16 (core)",
    "@oclif/plugin-warn-if-update-available 3.0.15 (core)",
    "@oclif/plugin-which 3.1.7 (core)",
    "@salesforce/cli 2.37.4 (core)",
    "apex 3.1.4 (core)",
    "auth 3.5.5 (core)",
    "data 3.2.5 (core)",
    "deploy-retrieve 3.5.6 (core)",
    "info 3.1.3 (core)",
    "limits 3.2.1 (core)",
    "marketplace 1.1.1 (core)",
    "org 4.0.4 (core)",
    "packaging 2.3.0 (core)",
    "schema 3.2.1 (core)",
    "settings 2.1.2 (core)",
    "sobject 1.2.2 (core)",
    "source 3.2.3 (core)",
    "telemetry 3.1.18 (core)",
    "templates 56.1.1 (core)",
    "trust 3.5.4 (core)",
    "user 3.4.3 (core)"
  ]
}

Additional information
Note: Running using a file with a json containing which tests to execute, also does not work.
Tests Done:

[ ] --tests Test1 --tests Test2 --tests "Test With Space" - FAILS
[ ] --tests "Test1, Test2, Test With Space" - FAILS
[ ] --tests Test1, Test2, "Test With Space" - FAILS
[ ] --tests Test1 Test2 "Test With Space" - FAILS

All of these tests done works with the MBP local environment.
Updates

Forcibly installed the same version of the local machine and same error. This doesn't seem to be related to sf cli version but something related to it.

npm install -g<EMAIL_ADDRESS>
 ›   Warning: @salesforce/cli update available from 2.15.9 to 2.37.4.

Updating Node and NPM to the latest, also didn't help.

##[debug] Node version after update
v20.12.2
##[debug] NPM version after update
10.5.0

{
  "architecture": "linux-x64",
  "cliVersion"<EMAIL_ADDRESS>  "nodeVersion": "node-v20.12.2",
  "osVersion": "Linux 6.5.0-1018-azure",
  "rootPath": "/usr/local/lib/node_modules/@salesforce/cli",
  "shell": "bash",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.0.13 (core)",
    "@oclif/plugin-commands 3.2.2 (core)",
    "@oclif/plugin-help 6.0.20 (core)",
    "@oclif/plugin-not-found 3.1.2 (core)",
    "@oclif/plugin-plugins 5.0.7 (core)",
    "@oclif/plugin-search 1.0.20 (core)",
    "@oclif/plugin-update 4.2.4 (core)",
    "@oclif/plugin-version 2.0.16 (core)",
    "@oclif/plugin-warn-if-update-available 3.0.15 (core)",
    "@oclif/plugin-which 3.1.7 (core)",
    "@salesforce/cli 2.37.4 (core)",
    "apex 3.1.4 (core)",
    "auth 3.5.5 (core)",
    "data 3.2.5 (core)",
    "deploy-retrieve 3.5.6 (core)",
    "info 3.1.3 (core)",
    "limits 3.2.1 (core)",
    "marketplace 1.1.1 (core)",
    "org 4.0.4 (core)",
    "packaging 2.3.0 (core)",
    "schema 3.2.1 (core)",
    "settings 2.1.2 (core)",
    "sobject 1.2.2 (core)",
    "source 3.2.3 (core)",
    "telemetry 3.1.18 (core)",
    "templates 56.1.1 (core)",
    "trust 3.5.4 (core)",
    "user 3.4.3 (core)"
  ]
}

you might want your shell script to echo out the command it's running.  I'm sure this is an error in your bash script.
Once you've done that, can you share the actual command that it's running?
I just added a test to do your scenario (two --tests flags https://github.com/salesforcecli/plugin-deploy-retrieve/pull/979) that runs on GHA.

I will check out the issue you mentioned to see if it is not related to GHA as well.

Those aren't issues, they're us running commands like yours (with 2 --tests) using GHA.  Hopefully you can see some difference between those and your script

Looks like from that PR you got the bash/quotes figured out.  The CLI doesn't need the quotes, but bash var expansion and/or string concat might.
I'll close this issue, but holler if I'm misunderstanding your PR.

Hi @mshanemc yes, after awhile I managed to get it running. I'm still testing to see if it works with a lot of tests classes. The goal is to only run the test classes for the component being deployed. Thanks for the assistance.


Where is custom patch button ?

Hello mate. I can't find patch button like maciasl. Where is the patch button ? I need to make battery patch but i can't insert B1B2 method and WECB,RECB etc. . Please develope this feature.

@tahaklkt-osxinfo use that kext instead of patching your DSDT
https://github.com/1Revenger1/ECEnabler

DSDT patches are old as hell and don't need them at all in QtiASL at all, as i think.
Most patches available as SSDTs in acidanthera and dortania docs

My laptop is very old. It has Intel Core I5 M430 nVidia GT 330M im using Catalina but ECEnabler isn't worked for me.

So im using Clover not Opencore.

@tahaklkt-osxinfo Opencore also works on some old systems. It also has a legacy option.
@tahaklkt-osxinfo I still use acpi patches. I even have my own patches. Many people still use them...
I should really like to see that in the future. (And also some other guys from the Facebook Hackintosh group)
I appreciate your work!

This patching feature won't be available in QtiASL because the patching method is obsolete, it's too old fashioned.
Also, even with very old hardware, whether you use OC or Clover, SSDT hot injection can be used to fix any problems you have, and it's time to phase out the modified DSDT approach.

I can understand what your saying as far as SSDT Hot Injection being the modern alternative that is suited for most people that are using a Hackintosh System. I respect that and I also understand the depths of the entire topic as well. The SSDT SYSTEM IS THE BEST for the "newbie" or for someone who does not care about the inner workings of the whole thing. But you should know as well as I do that patching a DSDT FOR ones own personal use is a solid method as well and is not obselete by any means. People that are in development with Linix kernel etc emloy it all the time still. I use it all the time. The prerequisite for all of this is that a person needs to know what they are doing. For newbies they should leave it alone completely. And stick with SSDT Because it works out of the box most of the time as long as one can follow instrucions! Anyways I appreciate your effort and your work here. Much respect to You brother. I am grateful for your contribution. If you choose to add new features so be it. If You dont You dont! I aint mad at ya lol! Peace


Move minimum OpenSSL version to 1.0.2

Discussed on dev ML, we're going to change minimum OpenSSL version to 1.0.2.
Thus we can assume OpenSSL 1.0.2 API and header files. It looks like we can remove below
Checking header file

HAVE_OPENSSL_EC_H
HAVE_OPENSSL_EVP_H ( actually, this was not checked )

Checking features

TS_USE_TLS_NPN
TS_USE_TLS_ALPN
TS_USE_CERT_CB
TS_USE_TLS_ECKEY

We still need some TS_CHECK_* stuff for APIs introduced by OpenSSL 1.1.0 and above.
Docs of APIs of each versions are below

https://www.openssl.org/docs/man1.0.2/man3/
https://www.openssl.org/docs/man1.1.0/man3/
https://www.openssl.org/docs/man1.1.1/man3/

This is incompatible change. Do NOT backport to 8.x.x branch.
Part of #5040. This will be ready for review after all other related PRs are merged.

[approve ci autest]
[approve ci debian]

[approve ci debian]

Somehow this change broke accepting HTTP/2. I will fix.

HTTP/2 is back! Ready for review.

[approve ci freebsd]

Looks like it is failing on Debian 8 because it doesn't have OpenSSL 1.0.2

[approve ci debian]

Now debian has openssl-1.0.2l, thanks @zwoop!
Is it time to ship this?

Ship it


Starting bot in sleep cycle

Actual
When starting the bot while it should be in a sleep cycle, it waits for start of next sleep cycle.
Expected
Bot should 'continue' sleeping and wake up on normal time.

Is this the intended behavior?

No, shouldn't be, sleep is sleep no matter when the bot starts.

@OniZakuma does it sleep after 1 cycle of the bot (i.e a couple of seconds), or does it wait until the next day when the sleep cycle should start (i.e. 20 hours or so)

No, it waits the full x-hours till next cycle starts.

Sleep schedule may need to be updated after https://github.com/PokemonGoF/PokemonGo-Bot/pull/2956/commits/081d90de32de84810120a50b238b70093e51ef17

#4031


v1.0.9 tagging issue

tesla powered thingies and industrial foregoing both use the 1.0.9 version. I am referring to the latest of each for 1.12.  However, 1.0.9 you tagged for 1.12.1 so they complain when you boot a dedicated server.
[11:20:59] [Server thread/FATAL] [FML]: The mod industrialforegoing (Industrial Foregoing) requires mod versions [teslacorelib@[1.0.9,)] to be available
[11:20:59] [Server thread/FATAL] [FML]: net.minecraftforge.fml.common.MissingModsException: Mod industrialforegoing (Industrial Foregoing) requires [teslacorelib@[1.0.9,)]
[11:20:59] [Server thread/FATAL] [FML]: The mod teslathingies (Tesla Powered Thingies) requires mod versions [teslacorelib@[1.0.9,)] to be available
[11:20:59] [Server thread/FATAL] [FML]: net.minecraftforge.fml.common.MissingModsException: Mod teslathingies (Tesla Powered Thingies) requires [teslacorelib@[1.0.9,)]

This can be fixed by tagging 1.0.9 for 1.12 so that TwitchApp can properly pull it.

you mean this:

?

Yes that
On Sep 22, 2017 10:25 AM, "faceofcat"<EMAIL_ADDRESS>wrote:

you mean this:
[image: image]
https://user-images.githubusercontent.com/23014228/30751880-5fb5e3d8-9fc3-11e7-8422-0b572220be1c.png
?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/faceofcat/Tesla-Core-Lib/issues/16#issuecomment-331478923,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADs0iDf1J83wTet9CrrlWS6WaLItg27zks5sk9FkgaJpZM4Pg3Eu
.

so... done! :)
please test and let me know if that fixes your issue.

It's fixed thanks
On Sep 22, 2017 11:38 AM, "faceofcat"<EMAIL_ADDRESS>wrote:

so... done! :)
please test and let me know if that fixes your issue.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/faceofcat/Tesla-Core-Lib/issues/16#issuecomment-331497806,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADs0iEr7Y9uub2Ssi8Rblec4xFYkqDL8ks5sk-KVgaJpZM4Pg3Eu
.


Refactor populate cursor, fix-wide-cursor

This refactors the populate cursor functions. It also applies the functional part of the fix-wide-cursor branch (i.e. does not apply the debug printlines.)
Tested with all three cursor modes. Tested with wide characters ａｓｄｆ.

Thanks for the PR  @OliverUv
Something is slightly broken here. Here's underline cursor on this PR. It's correct width, but char is hidden.

And here it is on master.

So, with this new commit the behavior is back to what it was before my branch.
However, I feel like it is/might be incorrect behavior in one way: the second cursor character is not printed when over wide characters. I'm not sure why this happens.
I've looked a bit at the rendering code. Doesn't seem to be doing any overwriting when adding new cells to the rendering buffer, unless something such happens during instancing that I'm not aware of.
I believe this is the first time in the codebase that RenderableCellsIter::cursor_cells contains more than 2 items, so perhaps there is some error in it's next method. Haven't spotted anything yet, though.

It looks like there might be a bug with the ArrayVec crate where you need to request one more capacity than is needed. I updated this with master and will merge shortly.

:clap:


[Mobile] Add a blackout background under the side panels

Description
Now it's possible to use the chat when the side panel open (open settings, context menu, etc.)

Expected: chat will be blocked by the blackout background

Use case/motivation
No response
Related issues
No response
Confidential information

[X] I confirm that do not share any confidential information

Verified on staging (mobile device - iPhone 15) successfully


Improve Logging

Add method entry/exit
Request logging should be further improve to record the parameters being sent to Instagram.

Closing the ticket... Re-open if needed


Compatibility changes while testing

Hello! I am rerunning a few of your code, just dropping a couple changes I had to make to get it to run, helpfully it will be helpful for you!

On your test notebook, the last import did not work in its original form, instead I had to change it to from run import data_process, test_plot. I presume the original script name might have been changed?
In the model.py script, I had to change one of the dgllife imports, originally it was:
from dgllife.model.readout.weighted_sum_and_max import WeightedSumAndMax, AttentiveFPReadout
I changed (split it) to:

from dgllife.model.readout.weighted_sum_and_max import WeightedSumAndMax
from dgllife.model.readout.attentivefp_readout import AttentiveFPReadout

Thanks for working on this!

Thanks for your suggestion! Regarding the import issues, it's possible that the original script has been updated or renamed, and we have made the necessary adjustments!


Remove mention of MacPorts ctypes issue

The fact that MacPorts exempi was incompatible with the
python-xmp-toolkit has not been the case for some time now.
Remove comment about this from the docs.
Closes-Issue: #6

Coverage decreased (-0.1%) to 96.833% when pulling 31c0702a77fd6563100220a5eeda16184dd61198 on quintusdias:issue6 into a07988cce6029e53873b0197f41ad34de68eeb4a on python-xmp-toolkit:devel.


Support schnorr signature

Hi
Any plan to support schnorr signature? some blockchains (e.g. Zilliqa) use it. There are some implementations using openssl, I wonder if trezor-crypto can support it too
Thanks

Yes, if someone implements it, I'll gladly merge the pull request.


Fix code search input for different views

Now only show the "code search" on the repo home page, because it only does global search.
So do not show it when viewing file or directory to avoid misleading users (it doesn't search in a directory)

When debugging, I also removed the unused IsRepoToolbarCommits by the way, and add some comments.


unwanted alpha change of non-hovered non-selected

Whn some bubble is selected, hovering a non-selected bubble increase the alpha of all bubbles.
The alpha increase of the hovered bubble, should not make an alpha transition, but just go to full alpha, to indicate the hover feedback as quickly as possible.

done


Pyright doesn't work anymore for unsafed buffers

It seems that LSP-pyright is now broken for unsafed buffers, for which the server is enabled by default. After you created such an unsafed buffer, the server simply doesn't respond to requests anymore, both for the buffer scheme and also for regular files, until it is restarted. It looks like as if an internal crash happend in the server.
https://github.com/sublimelsp/LSP-pyright/releases/tag/1.2.52 (pyright 1.1.333) seems to be the first affected version.

I can reproduce this. LSP-copilot seems to be a victim too (not sure what's going on under the hood). But sometimes it works while sometimes doesn't.

https://github.com/sublimelsp/LSP-pyright/assets/6594915/576b2f64-d342-4162-a063-1a35a4568b0e
Is that really a server issue? I can see :: [20:21:57.454] --> LSP-pyright shutdown (2): None.

May related to https://github.com/microsoft/pyright/issues/6314

I assume that it must be a server bug. It's not just the shutdown request, there are no more responses to any request and it doesn't send publishDiagnostic notifications anymore. So it's as if the server simply died after receiving a didOpen notification with buffer URI scheme.
I looked at a few commits in pyright between 1.1.332 and 1.1.333, and this one might be a possible cause because it seems to affect URI handling: https://github.com/microsoft/pyright/commit/cfe56bfb32ac66cfca5ed5c1aaab873d1adb1d4b (just speculation).
Perhaps something breaks for the buffer scheme now, because such a scheme wasn't considered since VS Code uses untitled for unsafed buffers. But a strange thing is that Pyright still works fine for the res scheme (from View Package File), so I might be wrong with that assumption.
Yeah, your linked issue looks like it is related.

VSCode's Pylance extension doens't seem to suffer from 100% CPU (with unsaved buffer).

https://github.com/sublimelsp/LSP/pull/2360
It was never able to return from this loop: https://github.com/microsoft/pyright/blob/a95a808e580f81bad6f35196b784b6b6fe13d8f7/packages/pyright-internal/src/analyzer/importResolver.ts#L508-L587
It the buffer://sublime/... path would never look like a "root" when trying to traverse that "path".

sublimelsp/LSP#2360

While it's fine to remove the sublime part in the URI, it should still be a valid URI even with that part, so I would say this is clearly a server bug and nothing that could be fixed in LSP.

The buffer://sublime/... URI would never look like a "root" when trying to traverse that "path".

The URIs for "View Package File" look like res://Packages/..., which is kind of similar, so it's unclear to me why the bug doesn't occur for those views if this would be the only cause.

Even with the PR merged I can still reproduce the server "dying" with the example from https://github.com/sublimelsp/LSP/pull/2360#issuecomment-1805055082. It happens right when you type import in an unsaved buffer.
So I guess this issue could be reopened, and for now I would suggest to remove the "buffer" in https://github.com/sublimelsp/LSP-pyright/blob/b0a03cfc743d95da123ae129795d49addfb88bb8/LSP-pyright.sublime-settings#L5 until it gets fixed in the server.

Pyright does something to the effect of file traversing that walks "up the tree" that causes this issue. Though not sure why would it do that for non-file URIs. Best to file an issue with it.

Wait, actually I wonder whether those are really valid URIs. I think buffer://42 is not a valid URI, because the path (here //42) must not begin with //.
https://datatracker.ietf.org/doc/html/rfc3986#section-3.3

If a URI does not contain an authority component, then the path cannot begin with two slash characters ("//").

Good point.
>>> import urllib;urllib.parse.urlparse('buffer://xx')
ParseResult(scheme='buffer', netloc='xx', path='', params='', query='', fragment='')

(netloc being the authority in this implementation, I believe)
That doesn't make the URI invalid, I don't think. It's just that the view id is parsed as authority here. And I suppose we don't really care about the authority/path part so it shouldn't matter for us.

But that would be a breaking change for us.

We can use "buffer" in plugin settings, but sents "untitled:foo" under the hood. Or deprecates "buffer" and introduces "untitled".

That doesn't make the URI invalid, I don't think. It's just that the view id is parsed as authority here. And I suppose we don't really care about the authority/path part so it shouldn't matter for us.

Ah, you're right, the path is empty in this case and the view_id will become the authority. While being a valid URI, I think it would be better to use an empty authority and non-empty path.
I would keep the buffer scheme, but adjust the URIs like this:
buffer:42
Perhaps this already fixes the bug with unsaved buffers in pyright.
I'm unsure about the res scheme, where for example Packages/Default/symbol.py looks like a path. But currently Packages will be the authority and /Default/symbol.py would be the path. Probably it makes more sense to leave authority empty here too and make Packages to be part of the path, like
res:Packages/Default/symbol.py
But on the other hand ST seems to already use res:// for the <img> tag in minihtml (https://www.sublimetext.com/docs/minihtml.html#tags), so maybe we should not care and leave it like that.

So I guess this issue could be reopened, and for now I would suggest to remove the "buffer" in
https://github.com/sublimelsp/LSP-pyright/blob/b0a03cfc743d95da123ae129795d49addfb88bb8/LSP-pyright.sublime-settings#L5
until it gets fixed in the server.

Done, with a release tagged.

Hi all, just want to know is this a pyright issue or LSP issue (or both?).
Pyright's maintainer is asking for a reproduction on https://github.com/microsoft/pyright/issues/6314#issuecomment-1809558332

This seems to be fixed in the latest pyright pyright 1.1.337.

In the release notes, I see:

Fixed bug that led to a hang (infinite loop) in the language server when opening a document whose URI wasn't a "file". This occurred in some language servers that used an "untitled" (or similar) URI type for new documents.


Documentation

Can I store my photos and movies  too in this storage or it is just a database?

I am closing all older issues. If this issue still exists in the latest version, please let me know.


Backup and Restore detailed design

Enabler

So that Data Lake content is well protected against potential data loss or corruption, we want to design proper data backup and restore processes.
Acceptance Criteria

[ ] User data and application data backup and restore processes detailed design is created and accepted by Data Lake team

Additional context

Tasks

[ ] Agree on Backup and Restore/Rollback requirements
[ ] Discuss Backup and Restore/Rollback options meeting requirements
[ ] Create Detailed design
[ ] Create follow-up stories

Definition of Ready

[ ] This story is ready to work on, according to the team's definition

Definition of Done

[ ] This story is done, according to the team's definition

@billgeo , this Story is not relevant anymore. Do we want to replace it with some more relevant detailed design story or just update current one ?

I think we close this one and create new stories. We had a quick conversation with Terence and made some decisions which can be the work we did on this one.


Flag for non-0 exit code if formatting changed the file

Hey there !
Would it be possible to add a couple of flags so that format-package could be executed as a pre-commit test? I saw it is possible to use lint-staged, but I have a pre-commit hook that checks if everything is OK and I'd like to check package.json too
This would be like this:
format-package [--check-formated,-c]

If the serialization of the formatted package.json is different to the actual file, this would return a non-0 exit code.
Thanks !

Hi @GerkinDev this seems like a good addition. Is this something you want to tackle?

Hi, I'm back on this since I'm reworking our CI process.
About this thing, how do you think this should behave?
On one hand, I would see this like most linters, eg not changing without a --fix flag.
On the other hand, this would be  a breaking change, probably not desirable.
So, maybe the best compromise would be like a --check-only flag, that would not format the file, but only checks for correctness, and return 1 exit code if invalid.

I would use a --check/-c flag.
If files changed from formatting (even if --write is passed) the process exits with a 1.
Additionally, if only --check/-c is passed, there is no format output printed in the console.

\o/ thank you so much for the merge! Have a wonderful day!

Do you have any idea about when you'll be able to release this on npm so that I can update my workflows?

@GerkinDev see #126


ci: Integration mutation tests with SonarCloud

Checklist before requesting a review

[x] I have performed a self-review of my code.
[x] Implemented tests for new features.
[x] I tested the features already implemented.
[x] Added usage examples in the readme.

:tada: This PR is included in version 1.6.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


[Proposal] Rename lettable operators namespace

At the moment we can import lettable operators this way:
import { concatAll } from 'rxjs/operator/concatAll';

Actually, this is wrong. It should be 'rxjs/operators/concatAll' not 'rxjs/operator/concatAll'.
Did you see it? "operators" not "operator".
The initial version gets us something still (the actual operator implementation, that's not lettable).
Which is exactly why this can be a source of confusion.
So, I suggest to change the new lettable operators from operators to lettable-operators or pipe-operators (maybe remove the last "s" too).

It's also worth noting that in VS Code, TypeScript seems to suggest the wrong import.
That if you write map(), concatAll, etc without importing them into a file, the quickfix from TypeScript will suggest that you import it from rxjs/operators while you really wanted them from rxjs/operator to use them with pipe().
It imports, then you get weird error about this, which only if you know this stuff well you can tell it's because what you imported is designed to work with prototype not use directly / with pipe().


strange error

I got a very strange error recently. I don't know whether or not it's file-loader's error. But I would be very pleased if you could figure out why this happen.
I ran into this trouble through image-webpack-loader, and I have commit a issue at that project. Here is the link.
Here's my errors:
Module build failed: ModuleBuildError: Module build failed: Error: spawn /Users/Zero/projects/livebet-client-code/node_modules/pngquant-bin/vendor/pngquant EAGAIN
at exports._errnoException (util.js:949:11)
at Process.ChildProcess._handle.onexit (internal/child_process.js:182:32)
at onErrorNT (internal/child_process.js:348:16)
at _combinedTickCallback (internal/process/next_tick.js:74:11)
at process._tickCallback (internal/process/next_tick.js:98:9)
at DependenciesBlock.onModuleBuildFailed (/Users/Zero/projects/livebet-client-code/node_modules/webpack-core/lib/NormalModuleMixin.js:315:19)
at nextLoader (/Users/Zero/projects/livebet-client-code/node_modules/webpack-core/lib/NormalModuleMixin.js:270:31)
at /Users/Zero/projects/livebet-client-code/node_modules/webpack-core/lib/NormalModuleMixin.js:292:15
at context.callback (/Users/Zero/projects/livebet-client-code/node_modules/webpack-core/lib/NormalModuleMixin.js:148:14)
at imagemin.buffer.then.catch.err (/Users/Zero/projects/livebet-client-code/node_modules/image-webpack-loader/index.js:42:9)
at process._tickCallback (internal/process/next_tick.js:103:7)
ERROR in<EMAIL_ADDRESS>Module build failed: Error: spawn /Users/Zero/projects/livebet-client-code/node_modules/pngquant-bin/vendor/pngquant EAGAIN
at exports._errnoException (util.js:949:11)
at Process.ChildProcess._handle.onexit (internal/child_process.js:182:32)
at onErrorNT (internal/child_process.js:348:16)
at _combinedTickCallback (internal/process/next_tick.js:74:11)
at process._tickCallback (internal/process/next_tick.js:98:9)
@ ./~/css-loader?sourceMap&localIdentName=[path][name]---[local]---[hash:base64:5]!./~/postcss-loader!./feSRC/view/pages/profile/index.scss 6:13630-13675

I have figured out a way to avoid this problem. link


stats: Implement TotalSamplesPerStep

This is an attempt at implementing the samples per step stats
Changes

Implemented total sample per step.
Fixed double counting of total samples in subquery.
Improved the unit tests for stats. The maxSamples and samplesPerStep stats now matches what the prometheus PromQL engine returns.

Note

I had to add a Subquery() method to the OperatorTelemetry to avoid double counting. It isn't the cleanest code. I'm open to suggestions about other ways to do this.

Requesting reviews. @fpetkovski @MichaHoffmann could you please take a look?

Just one question from my side, what is the difference between IncrementSamplesAtStep(samples int, step int) and IncrementSamplesAtTimestamp(samples int, t int64)? Do we still need both methods?

@fpetkovski - Thanks for asking this question. It prompted me to look deeper and uncover a bug.
IncrementSamplesAtTimestamp should be used when we don't know the correct step index. This is always the case in the new engine because of stepsBatch.
See: https://github.com/prometheus/prometheus/blob/71c90c71d41948eea3f33dfd3ee0a5cc581a36f3/util/stats/query_stats.go#L290

We should always use IncrementSamplesAtTimestamp() in the new engine. In the new engine, we only know the timestamp and not the step index. This is because of the batching using stepsBatch.
This is what would happen if IncrementSamplesAtStep() is used in the VectorSelector. In the below example range query, there are a total of 61 steps which are executed in 7 batches of 10 steps.
{
  name: "vector selector",
  load: `load 30s
   http_requests_total{pod="nginx-1"} 1+1x1000
   http_requests_total{pod="nginx-2"} 1+2x1000`,
  query: `http_requests_total{pod="nginx-1"}`,
  start: time.Unix(0, 0),
  end:   time.Unix(1800, 0),
  step:  time.Second * 30,
},

// Old engine
exp: []int64{1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1}

// New engine
got: []int64{7, 6, 6, 6, 6, 6, 6, 6, 6, 6, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}

Since at the start of each batch, the currStep is reset to 0, the samples will always be counted towards the first 10 steps (assuming stepsBatch=10).
When IncrementSamplesAtTimestamp() is used instead, it will correctly increment the sample for the timestamp of the step irrespective of the batch.

I will remove IncrementSamplesAtStep() from the code base and always use IncrementSamplesAtTimestamp(). I will also extend the tests to cover multiple batches.

The fuzz failure doesn't seem related to this change.


I send my clone project url than I see your github profile image in everywhere.

LIKE THIS

@faizkhan7896 Edit Line 25 and add URL of desired image in pages/index.js


[BUG] OS updates wiping knn_vector field when excluded from _source

What is the bug?
I have an index with a knn_vector field that I excluded from _source. When I update a document in this index without specifying any value for the knn_vector field, the field gets wiped from the document (when I would expect the field to remain unchanged).
How can one reproduce the bug?

Go to OS dashboards.
Create an OS index with knn vector field:

PUT /test
{
  "settings": {
      "index": {
        "replication": {
          "type": "DOCUMENT"
        },
        "knn": "true"
      }
    },
    "mappings": {
      "dynamic": "strict",
      "_source": {
        "excludes": [
          "embedding"
        ]
      },
      "properties": {
        "embedding": {
          "type": "knn_vector",
          "dimension": 1,
          "method": {
            "engine": "faiss",
            "space_type": "l2",
            "name": "hnsw",
            "parameters": {}
          }
        },
        "creator_id": {
          "type": "keyword"
        },
        "file_id": {
          "type": "long"
        }
      }
    }

}

Create a document in the index.

PUT /test/_doc/1
{
  "creator_id": "2",
  "file_id": 22,
  "embedding":[0.1]
}

Check to see if the knn vector field (embedding) exists on the document (the below command should return the single document).

GET test/_search
{
  "query": {
    "bool": {
      "must": [
        {
          "exists": {
            "field": "embedding"
            }
        }
      ]
    }
  }
}

Update the document with an update on the non-knn vector field.

POST test-v6/_update/1
{
  "doc": {
    "file_id": 24
  }
}

Check to see if the document has exists with the knn_vector field by running the same command in step 4 (now returns no documents).

What is the expected behavior?
I would expect the knn_vector field to still exist after the update, because I have not made any changes to that field.
What is your host/environment?
Opensearch version 2.11, hosted on AWS
Do you have any additional context?
In an index where the knn_vector field (embedding) is NOT excluded from _source, this problem is not present.

@claire-chiu-figma as you are not storing the _source, the updates will lead to removal of vector. This is not a bug, but this is what removal of _source will happen.

We are working on another feature ref: https://github.com/opensearch-project/k-NN/pull/1571 where if you remove _source and then do updates too the vector field should not be removed.
@luyuncheng as you are the author of the PR. can you validate that removing the _source and then doing updates will work once your code is merged?

Thanks for the quick response -

This is not a bug, but this is what removal of _source will happen.
To further understand the implications of removing a field from _source - does this mean that for ANY field that is excluded from _source, when you run an update on the document, if the update does not specify a new value for that field, that field will get wiped? Why is that so?

if the update does not specify a new value for that field, that field will get wiped? Why is that so?

The reason is there is no way Opensearch has the way to recreate the whole document from scratch. The whole document gets stored in _source so if you remove it then update capability goes away.

I see, and https://github.com/opensearch-project/k-NN/pull/1571 would help resolve this issue even if the vector is excluded from _source, because it would store the vector in docvalue_fields, which can be pulled from during an update operation?

I see, and #1571 would help resolve this issue even if the vector is excluded from _source, because it would store the vector in docvalue_fields, which can be pulled from during an update operation?

So vectors are already stored in doc_values. What the above PR will do is it will ensure that vectors get pulled from doc values if they are not present in _source. I would like @luyuncheng to comment more as he is author of the PR.

@navneet1v apart from the PR that's being worked on, are there any other approaches to issuing partial updates without wiping the vector? Or is adding this back to _source the only option?

@claire-chiu-figma if you can create the whole source back again and use it in your update API that is the only way. Otherwise you have to enable the source.

@claire-chiu-figma can I go ahead and close this issue. As there is no bug and this is the expected behavior of the Opensearch.

@navneet1v  @claire-chiu-figma
when excluded from _source and do update operation, it goes to logic:
https://github.com/opensearch-project/OpenSearch/blob/14f1c43c108f378b13d109ade364216c082fb858/server/src/main/java/org/opensearch/index/engine/InternalEngine.java#L1311-L1318
it using lucene source to do update. as i know, in the original reference there is a warning that when exclude source, we can not use update, update_by_query, reindex APIs
and if we wan to use #1571 features, which is rewrite the FetchSubPhase, it can do reindex but not update the other field.
there is 2 scenarios:

exclude vector, update vector field: OK
exclude vector, update other field:  Failed

Covered in #1572


How to use it

Hello Aakash, I have downloaded your projects and would love to test it.
What instructions to type please ?

Hi,
You can visit this link which'll tell you more about the contents of these codes and how do they function.
http://aakashjapi.com/fuckin-search-engines-how-do-they-work/


ChangeEmailRequest should change username in case of EmailIsUsername and not RequireAccountVerification

The ChangeEmailRequest checks the RequireAccountVerification config value. If no verification is required the e-mailaddress is changed without sending a verification request first, which is fine.
However when the e-mailaddress is also the username, the username is not changed by this method. This leads to unexpected behavior. Because when the account was created the user could login with an unverified username (=e-mailaddress) but when we want to change the username (which needs to be done through ChangeEmailRequest because ChangeUsername cannot be used when EmailIsUsername) the verification must be done in order for the change to take effect.
Why? :-)

IIRC we don't want to trust the new email until the new email has been confirmed. If you change it prior to that then the account is in an inconsistent state.

Thanks for the quick response Brock.
The e-mail is changed and the account state is set to not verified:
 if (!Configuration.RequireAccountVerification)             {                 Tracing.Verbose("[UserAccountService.ChangeEmailRequest] RequireAccountVerification false, changing email");                 account.IsAccountVerified = false;                 account.Email = newEmail;                 this.AddEvent(new EmailChangedEvent<TAccount> { Account = account, OldEmail = oldEmail, VerificationKey = key });                 Update(account);             }             else             {                 Tracing.Verbose("[UserAccountService.ChangeEmailRequest] RequireAccountVerification true, sending changing email");                 this.AddEvent(new EmailChangeRequestedEvent<TAccount> { Account = account, OldEmail = oldEmail, NewEmail = newEmail, VerificationKey = key });                 UpdateInternal(account);             }
So the state of the account is the same as it would be when you created it with the RequireAccountVerification set to false, however the only thing off is the username.


Issue with @connectrpc/connect-query: Module not found: Error: Can't resolve './use-transport'

Hi there 👋
Unfortunately after upgrading to use @connectrpc/connect-query, I found that my app stopped working. I am using a regular CRA setup, and it seems that despite the package exporting both CommonJS and ESM, some of the modules cannot be found, use-transport, create-use-query-options and create-use-infinite-query-options to name a few.
I tried using
import { useQuery } from '@connectrpc/connect-query/dist/cjs/use-query';

instead, but it doesn't seem to alleviate the issue.
Also it might be worth mentioning that npmjs has a @connectrpc/connect-react-query release 1.0.0-rc.1 which might confuse some people, perhaps it might be worth removing it if @connectrpc/connect-query should be used instead?
Please find the issue below:
ERROR in<EMAIL_ADDRESS>16:0-47
Module not found: Error: Can't resolve './use-transport' in 'app/node_modules/@connectrpc/connect-query/dist/esm'
Did you mean 'use-transport.js'?

BREAKING CHANGE: The request './use-transport' failed to resolve only because it was resolved as fully specified
(probably because the origin is strict EcmaScript Module, e. g. a module with javascript mimetype, a '*.mjs' file, or a '*.js' file where the package.json contains '"type": "module"').
The extension in the request is mandatory for it to be fully specified.
Add the extension to the request.
ERROR in<EMAIL_ADDRESS>15:0-67
Module not found: Error: Can't resolve './create-use-query-options' in 'app/node_modules/@connectrpc/connect-query/dist/esm'
Did you mean 'create-use-query-options.js'?

BREAKING CHANGE: The request './create-use-query-options' failed to resolve only because it was resolved as fully specified
(probably because the origin is strict EcmaScript Module, e. g. a module with javascript mimetype, a '*.mjs' file, or a '*.js' file where the package.json contains '"type": "module"').
The extension in the request is mandatory for it to be fully specified.
Add the extension to the request.
ERROR in<EMAIL_ADDRESS>16:0-47
Module not found: Error: Can't resolve './use-transport' in 'app/node_modules/@connectrpc/connect-query/dist/esm'
Did you mean 'use-transport.js'?

BREAKING CHANGE: The request './use-transport' failed to resolve only because it was resolved as fully specified
(probably because the origin is strict EcmaScript Module, e. g. a module with javascript mimetype, a '*.mjs' file, or a '*.js' file where the package.json contains '"type": "module"').
The extension in the request is mandatory for it to be fully specified.
Add the extension to the request.
ERROR in<EMAIL_ADDRESS>15:0-84
Module not found: Error: Can't resolve './create-use-infinite-query-options' in 'app/node_modules/@connectrpc/connect-query/dist/esm'
Did you mean 'create-use-infinite-query-options.js'?

BREAKING CHANGE: The request './create-use-infinite-query-options' failed to resolve only because it was resolved as fully specified
(probably because the origin is strict EcmaScript Module, e. g. a module with javascript mimetype, a '*.mjs' file, or a '*.js' file where the package.json contains '"type": "module"').
The extension in the request is mandatory for it to be fully specified.
Add the extension to the request.

Sorry about that. Looks like JS module system is at it again. Gotta get around to fixing #186. In the mean time, I'll fix the import issue.

Thanks a lot @paul-sachs for the quick fix, really appreciate it. Would it be possible to cut a new release with these changes? Thank you

Yeah. I'm just reviewing a few more issues to get into the release. Will do a release today.

Sorry for the delay. This bug has been fixed with release v1.1.0.


Fixups to enable building this branch with clang

Note this is a PR against your pg-splinterdb-shmem-integn-1 branch.
My editor uses clang for various IDE-like things.  It's nice to have this branch buildable with clang.

Turns out removing the static broke the GCC build.  So I undid that and fixed it a different way: https://github.com/vmware/splinterdb/commit/b9ea7ef29acdd0d5ce6c34211bfde3d14adb7093
Pushed that fix directly to the branch since it was so small.