feat: 增加搜索高亮交互状态及主题色

👀 PR includes

✨ Feature

[x] New feature

📝 Description
下个PR TODO:

[ ] s2-react 增加指标搜索组件
[ ] 相关文档和 demo

🔗 Related issue link

🔍 Self Check before Merge

[ ] Add or update relevant Docs.
[ ] Add or update relevant Demos.
[ ] Add or update relevant TypeScript definitions.

:tada: This PR is included in version @antv/s2-v1.14.0-alpha.4 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version @antv/s2-v1.15.0-alpha.1 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version @antv/s2-v1.16.0-alpha.1 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version @antv/s2-v1.17.0-alpha.1 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version @antv/s2-v1.18.0-alpha.1 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version @antv/s2-v1.21.0-alpha.1 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version @antv/s2-v1.23.0-alpha.1 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version @antv/s2-v1.24.0-alpha.1 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version @antv/s2-v1.26.0-alpha.1 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version @antv/s2-v1.28.0-alpha.1 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version @antv/s2-v1.30.0-alpha.1 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version @antv/s2-v1.31.0-alpha.1 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version @antv/s2-v1.33.0-alpha.1 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version @antv/s2-v1.40.0-alpha.1 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


feat: notify user on new pwa update

https://angular.io/guide/service-worker-communications

The app should focus on the plugin demos. For this reason, adding this feature is no longer planned.


fix(lnd): increase lnd debug level

Description:
Increase lnd debug level
Motivation and Context:
At some point recently, the lnd log level has reverted from debug to info. We rely on debug level log output from lnd in order to monitor it's sync process when running as a local neutrino client. We are missing some of the messages that only show on the debug level, which we use to determine the sync state and as a result the progress bnar is updating very infrequently.
How Has This Been Tested?
Manually - note, granularity and regularity of sync progress updates is increased.
Types of changes:
Bug fix
Checklist:

[x] My code follows the code style of this project.
[x] I have reviewed and updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes where needed.
[x] All new and existing tests passed.
[x] My commits have been squashed into a concise set of changes.

Coverage remained the same at 19.395% when pulling dded52cb12ce13ee0ca268e784b822f0b6b17d1b on mrfelton:fix/lnd-loglevel into 76b8a9e7f92e27be6576a540802c9ad118842197 on LN-Zap:master.


accessibility and assistive technology testing in CI/CD pipeline

self-ping: need to revisit, loooking for aappropriate tooling


Use correct value to fix percentage change

This was broken when we moved to CoinGecko.
Will do a followup PR to remove all references to CMC and instead refer to prices as fiatPrice instead of cmcPrice etc.

👍 Looks good.


Update FR.ini

Add more string for/and translate

I will merge all these pull requests, then retcon a few of the translations, some of them were MEANT to be wrong such as 'News' instead of 'internet browser'. To make it really seem like a nintendo switch when you're in view #5. There are a number of good fixes you have put though that will be kept. And thank you for reminding me that I need to translate in the triangle menu.
I will get it all sorted out and probably add a few languages

Thanks !!!


Exception when using with F#

I am trying to use ilrepack on my OSX for https://github.com/dungpa/fantomas F# executable.
I got the nuget package and ran this command
➜  ~  mono ILRepack.exe /out:/Users/naveen/temp/fant/Fantomas.exe
../../Fantomas.2.0.2/lib/Fantomas.exe ../../Fantomas.2.0.2/lib/FSharp.CompOCiler.Service.dll
../../Fantomas.2.0.2/lib/FantomasLib.dll ../../Fantomas.2.0.2/lib/FSharp.Core.dll

which did compile it into a single executable but when I try and use the executable I get an exception
➜  fant  mono Fantomas.exe ~/code/adventofcode/1.fsx
The following exception occurs while formatting stdin: System.InvalidProgramException: Invalid IL code in Microsoft.FSharp.Compiler.SourceCodeServices.LexerStateEncoding:decodeLexInt (long): IL_008c: ldloc.2

   at Microsoft.FSharp.Compiler.SourceCodeServices.FSharpLineTokenizer.ScanToken (Int64 lexState) in <filename unknown>:line 0
   at<EMAIL_ADDRESS>(IEnumerable`1& next) in <filename unknown>:line 0
   at Microsoft.FSharp.Core.CompilerServices.GeneratedSequenceBase`1[T].MoveNextImpl () in <filename unknown>:line 0
   at Microsoft.FSharp.Core.CompilerServices.GeneratedSequenceBase`1[T].System-Collections-IEnumerator-MoveNext () in <filename unknown>:line 0
   at Microsoft.FSharp.Collections.SeqModule.ToList[T] (IEnumerable`1 source) in <filename unknown>:line 0
   at Fantomas.TokenMatcher.filterConstants (System.String content) in <filename unknown>:line 0
   at Fantomas.TokenMatcher.filterDefines (System.String content) in <filename unknown>:line 0
   at Fantomas.CodeFormatterImpl.createFormatContextNoChecker (System.String fileName, System.String source) in <filename unknown>:line 0
   at Fantomas.CodeFormatter.FormatDocument (System.String fileName, System.String source, Fantomas.FormatConfig config) in <filename unknown>:line 0
   at Fantomas.Cmd.Program.processSourceString (Boolean isFsiFile, System.String s, System.IO.TextWriter tw, Fantomas.FormatConfig config) in <filename unknown>:line 0
   at Fantomas.Cmd.Program.stringToFile@185 (Microsoft.FSharp.Core.FSharpRef`1 force, Microsoft.FSharp.Core.FSharpRef`1 profile, Microsoft.FSharp.Core.FSharpRef`1 fsi, System.String s, System.String outFile, Fantomas.FormatConfig config) in <filename unknown>:line 0

Am I missing some option? Please let me know. Thanks

Thx for the report, fixed in #140

Thanks. When will it is likely to be merged?

Merge is done, release in progress

Thank you!


refactor the code for PR of packer official site

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


[rangeslider] max range now defaults to 0

Describe the bug
on 8.0.5 now max range is 0 by default: minimumValue defaults to 0,  minimumRange 0, and minimumValue + minimumRange = 0
To Reproduce
n/a
Expected behavior
n/a
Screenshots
n/a
Please complete the following information:
n/a
Additional context
n/a

Ah, damn. I should have make it a breaking change and update the readme accordingly. My bad. I'll fix asap.

Solved in 8.0.6. Sorry for the mess. The new defaults will start from 9.0.0 and the documentation will be updated accordingly.


construct huffman table from symbol spans

Define class template symbol_span that represents an inclusive range
from first to last. The symbol_bitsize constructor of huffman::table
now takes a range of pair-likes of symbol_span and bitsize, allowing
the same bitsize to be associated with a contiguous range of symbols.
For example, the static Huffman tree corresponding to the literal/length
alphabet in section 3.2.6 of the DEFLATE RFC can be defined as:
 constexpr auto table =
  huffman::table<std::uint16_t, 288>{
    huffman::symbol_bitsize,
    {{{  0, 143}, 8},
     {{144, 255}, 9},
     {{256, 279}, 7},
     {{280, 287}, 8}}};

resolves #91
Change-Id: I50f7ea63561de0bb785c85467cdb943829b65edf

Codecov Report

Merging #97 (cd79f25) into Ia125173ce91e2e189c23de0956d9eaa7aa51762c (3cb36c5) will increase coverage by 0.15%.
The diff coverage is 100.00%.

:exclamation: Current head cd79f25 differs from pull request most recent head b8a3e0d. Consider uploading reports for the commit b8a3e0d to get more accurate results

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
@@                              Coverage Diff                              @@
##           Ia125173ce91e2e189c23de0956d9eaa7aa51762c      #97      +/-   ##
=============================================================================
+ Coverage                                      98.61%   98.76%   +0.15%
=============================================================================
  Files                                             11       13       +2
  Lines                                            288      325      +37
=============================================================================
+ Hits                                             284      321      +37
  Misses                                             4        4

Files
Coverage Δ

...ffman/src/detail/flattened_symbol_bitsize_view.hpp
100.00% <100.00%> (ø)

huffman/src/encoding.hpp
100.00% <ø> (ø)

huffman/src/symbol_span.hpp
100.00% <100.00%> (ø)

huffman/src/table.hpp
97.22% <100.00%> (+0.07%)
:arrow_up:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

I made a couple of very minor changes and pushed. We can discuss the other stuff next time we meet if you want.


chore: make ListObjects tests more readable

It's the same ListObjects tests that we have right now, but

they hit the API, not the internal commands.
they should be easier to read and add more to them
they test both the Reverse Expansion and Concurrent checks implementations

Codecov Report
Patch coverage: 96.68% and project coverage change: -0.14 :warning:

Comparison is base (c9d53e9) 84.45% compared to head (a3c6c01) 84.31%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #599      +/-   ##
==========================================
- Coverage   84.45%   84.31%   -0.14%
==========================================
  Files          86       86
  Lines       13573    13512      -61
==========================================
- Hits        11463    11393      -70
- Misses       1735     1740       +5
- Partials      375      379       +4

Impacted Files
Coverage Δ

pkg/storage/test/tuples.go
92.45% <91.66%> (-0.24%)
:arrow_down:

pkg/server/test/list_objects.go
56.29% <100.00%> (-19.74%)
:arrow_down:

pkg/server/test/server.go
87.17% <100.00%> (ø)

pkg/storage/mysql/mysql.go
76.49% <100.00%> (-0.44%)
:arrow_down:

pkg/storage/postgres/postgres.go
78.19% <100.00%> (-0.46%)
:arrow_down:

tests/listobjects/listobjects.go
100.00% <100.00%> (+11.39%)
:arrow_up:

pkg/storage/storage.go
66.00% <0.00%> (-3.00%)
:arrow_down:

internal/graph/check.go
89.04% <0.00%> (-0.92%)
:arrow_down:

... and 5 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


fix: command steps are executed twice

Proposed changes

Types of changes

[x] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Improvement (general improvements like code refactoring that doesn't explicitly fix a bug or add any new functionality)
[ ] Documentation Update (if none of the other choices apply)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Paste Link to the issue
https://github.com/thin-edge/thin-edge.io/issues/2896
Checklist

[ ] I have read the CONTRIBUTING doc
[ ] I have signed the CLA (in all commits with git commit -s)
[ ] I ran cargo fmt as mentioned in CODING_GUIDELINES
[ ] I used cargo clippy as mentioned in CODING_GUIDELINES
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have added necessary documentation (if appropriate)

Further comments

The issue has been successfully reproduced with this test run https://github.com/thin-edge/thin-edge.io/actions/runs/9502721361/job/26191697380?pr=2937.
There is a duplicate for the restarted state:
----------------------[ issue-2896 @ init
----------------------[ issue-2896 @ executing
----------------------[ issue-2896 @ await_restart
----------------------[ issue-2896 > restart @ init
----------------------[ issue-2896 > restart @ scheduled
----------------------[ issue-2896 > restart @ executing
----------------------[ issue-2896 > restart @ executing
----------------------[ issue-2896 @ await_restart
----------------------[ issue-2896 > restart @ successful
----------------------[ issue-2896 @ restarted
----------------------[ issue-2896 @ restarted

The root cause of issue is that, before these updates,
the invoking operation of a terminated sub-operation was not directly resumed, as of now, but queued for later processing.
Similarly, the pending commands were queued for execution on restart of the agent.
This has also been changed: now the commands are directly resumed on start, and no more queued.
This second point was not causing any issue but has been a source of confusion reading the logs.
So why queuing the resumed operations on sub-operation termination was causing a duplicated thread of execution?
And why queuing the resumed operations on agent restart was leading to confusing logs?
Taking the workflow reproducing the issue as a basis (see tests/RobotFramework/tests/tedge_agent/workflows/issue-2896.toml),
and the faulty execution log /var/log/tedge/agent/workflow-issue-2896-test-1.log
(see here)
the critical steps occurred on restart.

Two pending steps are resumed on boot issue-2896 > restart @ executing and issue-2896 @ await_restart,
then queued without being logged!.
issue-2896 > restart @ executing is popped from the queue and processed.
The agent detects the restart has been successful and moves to issue-2896 > restart @ succesful.
Again this new state is queued and not immediately logged (it will be logged when popped from the queue).
issue-2896 @ await_restart is popped from the queue and processed.
Even if this has not been logged, the fact the sub operation has been successful has been persisted by the agent.
Hence, this step is successful and issue-2896 @ restarted is queued (again silently).
issue-2896 > restart @ succesful is now popped from the queue.
The sub operation been terminated, the agent blindly reschedules the current state of the invoking operation,
queuing a duplicated issue-2896 @ restarted (i.e. the persisted state of the invoking operation).
Then, we have two threads of execution.

The issue could have probably been fixed by avoiding to blindly resume the invoking operation check.
But, besides the fact it was not so direct to implement, and also because the logs were so messy to interpret,
I preferred to opt in for a more direct solution and came with the following updates.
First, next steps are logged as in:
----------------------[ issue-2896 @ await_restart | time=2024-06-18T15:10:41.590001656Z ]----------------------

Action:   await sub-operation completion

=> restart sub-operation is successful
=> moving to issue-2896 @ restarted

Second, resumed operations are immediately executed and no more queued.
So we can observe all the steps on restart:
--[ issue-2896 @ await_restart        # resumed on restart: successful restart not detected yet => back to sleep
--[ issue-2896 > restart @ executing  # resumed on restart: successful restart detected => queue `issue-2896 > restart @ successful`
--[ issue-2896 > restart @ successful # resume the invoking command => execute `issue-2896 @ await_restart`
--[ issue-2896 @ await_restart        # proceed on reboot success => queue `issue-2896 > restarted`

As the two pending operations could be resumed in a different order (rust hashmaps are not deterministic),
a second thread of execution is also observable:
--[ issue-2896 > restart @ executing  # resumed on restart: successful restart detected => queue `issue-2896 > restart @ successful`
--[ issue-2896 @ await_restart        # resumed on restart: successful restart not detected yet => back to sleep
--[ issue-2896 > restart @ successful # resume the invoking command => execute `issue-2896 @ await_restart`
--[ issue-2896 @ await_restart        # proceed on reboot success => queue `issue-2896 > restarted`

The issue is fixed by the fact there is no more interleaved step executions
between issue-2896 > restart @ successful and issue-2896 @ await_restart.


New Firmware not installing because of wrong md5 path inside firmware-update.sh

Hi,
new firmware could not be installed because of a wrong path to the md5 file. See row 72 in firmware-update.sh:
md5=$(curl --fail --silent "${FW_BASE%/}/${fileName}.md542")
There is no *.md542 in ${FW_BASE%}.
After changing to
md5=$(curl --fail --silent "${FW_BASE%/}/${fileName}.md5")
the download and install of the newest firmware for my ConBeeII went perfectly fine.
http://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x26650700.bin.GCF
Please fix this typo.

Fixed this annoying thing with #273

Does this solve this error?
`~ $ docker run -it --rm --entrypoint "/firmware-update.sh" --privileged --cap-add=ALL -v /dev:/dev -v /lib/modules:/lib/modules -v /sys:/sys marthoc/deconz:latest
         marthoc/deconz Firmware Flashing Script

                   Version: 0.6

Listing attached devices...
GCFFlasher V3_15 (c) dresden elektronik ingenieurtechnik gmbh
Path             | Vendor | Product | Serial     | Type
-----------------+--------+---------+------------+-------
/dev/ttyACM0     | 0x1CF1 | 0x0030  |            | ConBee II
/dev/ttyACM1     | 0x1CF1 | 0x0030  |            | ConBee II
Enter the full device path, or press Enter now to exit.
Device Path : /dev/ttyACM0

Firmware available for flashing:
deCONZ_ConBeeII_0x264a0700.bin.GCF
deCONZ_ConBeeII_0x26580700.bin.GCF
deCONZ_Rpi_0x26330500.bin.GCF
deCONZ_Rpi_0x26350500.bin.GCF
Enter the firmware file name from above, including extension.
Alternatively, you may enter the name of a firmware file to download
from http://deconz.dresden-elektronik.de/deconz-firmware/
or press Enter now to exit.
File Name : deCONZ_ConBeeII_0x26650700.bin.GCF
File not found locally. Try to download?
Enter Y to proceed, any other entry to exit: Y
Downloading...
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
Dload  Upload   Total   Spent    Left  Speed
100  160k  100  160k    0     0   270k      0 --:--:-- --:--:-- --:--:--  270k
Download complete! Checking md5 checksum...
md5sum: 'standard input': no properly formatted MD5 checksum lines found
Error comparing checksums! Please re-run this script...
`

Does this solve this error?
`~ $ docker run -it --rm --entrypoint "/firmware-update.sh" --privileged --cap-add=ALL -v /dev:/dev -v /lib/modules:/lib/modules -v /sys:/sys marthoc/deconz:latest
-------------------------------------------------------------------

             marthoc/deconz Firmware Flashing Script

                       Version: 0.6

-------------------------------------------------------------------

[...]

Download complete! Checking md5 checksum...
md5sum: 'standard input': no properly formatted MD5 checksum lines found

Error comparing checksums! Please re-run this script...

Yes, that's exactly the behaviour caused by the typo.
The script tries to download the .md542 to compare it's content to the md5sum of the firmware file. As there isn't such a file the script exits with an error.
Even worse: the script does a cleanup after exiting. Otherwise you would have seen the downloaded file on the next run.

Same problem with new firmware deCONZ_ConBeeII_0x26660700.bin.GCF
-------------------------------------------------------------------

             marthoc/deconz Firmware Flashing Script

                       Version: 0.6

-------------------------------------------------------------------

Listing attached devices...

GCFFlasher V3_15 (c) dresden elektronik ingenieurtechnik gmbh
Path             | Vendor | Product | Serial     | Type
-----------------+--------+---------+------------+-------
/dev/ttyACM0     | 0x1CF1 | 0x0030  |            | ConBee II
/dev/ttyAMA0     | 0x0000 | 0x0000  |            | RaspBee

Enter the full device path, or press Enter now to exit.

Device Path : /dev/ttyACM0

-------------------------------------------------------------------

Firmware available for flashing:
deCONZ_ConBeeII_0x264a0700.bin.GCF
deCONZ_ConBeeII_0x26580700.bin.GCF
deCONZ_Rpi_0x26330500.bin.GCF
deCONZ_Rpi_0x26350500.bin.GCF

Enter the firmware file name from above, including extension.
Alternatively, you may enter the name of a firmware file to download
from http://deconz.dresden-elektronik.de/deconz-firmware/
or press Enter now to exit.

File Name : deCONZ_ConBeeII_0x26660700.bin.GCF

File not found locally. Try to download?
Enter Y to proceed, any other entry to exit: y

Downloading...

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  160k  100  160k    0     0   438k      0 --:--:-- --:--:-- --:--:--  439k

Download complete! Checking md5 checksum...
md5sum: 'standard input': no properly formatted MD5 checksum lines found

Error comparing checksums! Please re-run this script...

Tested also manual downloading file directly to /usr/share/deCONZ/firmware/, but script dont recognize it.

Tested also manual downloading file directly to /usr/share/deCONZ/firmware/, but script dont recognize it.

Just edit the firmware-update.sh like I showed in post #1.

Tested also manual downloading file directly to /usr/share/deCONZ/firmware/, but script dont recognize it.

Just edit the firmware-update.sh like I showed in the first post.

Cannot find them. Upgraded on Windows :)

I tried to update the script but its also not recognizing...
I downloaded the script and copied it inside the container.

I tried to update the script but its also not recognizing...
I downloaded the script and copied it inside the container.

maybe this could help you:
sudo docker run --name=deconz-fw -d -it --name=deconz-fw --entrypoint "/firmware-update.sh" --privileged --cap-add=ALL -v /dev:/dev -v /lib/modules:/lib/modules -v /sys:/sys marthoc/deconz
sudo docker exec -it deconz-fw bash
# inside the container, run:
apt update
apt install nano
nano firmware-update.sh
# remove the 42 in row 72. Result:
        md5=$(curl --fail --silent "${FW_BASE%/}/${fileName}.md5")
# save file and exit container
sudo docker stop deconz-fw
sudo docker start -i deconz-fw
# install your favorite fw file. ex. deCONZ_ConBeeII_0x26650700.bin.GCF
sudo docker rm deconz-fw

If not, just wait for the next version of  marthoc/deconz. It will be fixed.

That worked, thanks alot! 👍 :-)

# inside the container, run:
apt update
apt install nano
nano firmware-update.sh
# remove the 42 in row 72. Result:
        md5=$(curl --fail --silent "${FW_BASE%/}/${fileName}.md5")
# save file and exit container

To modify the firmware-update.sh you could just run this from outside the container.
sudo docker exec -it deconz-fw bash -c 'sed -i s/md542/md5/ firmware-update.sh'

... or use it with the appropriate container name. sed is available inside the deconz-container and therefore no installation is needed.

Putting all into one: if you want to download the firmware the way it should have been - call this:
sudo docker run -it --rm --entrypoint "sh" --privileged --cap-add=ALL -v /dev:/dev -v /lib/modules:/lib/modules -v /sys:/sys marthoc/deconz '-c' 'sed -i -e "s/md542/md5/" firmware-update.sh;./firmware-update.sh'

sudo docker exec -it deconz-fw bash -c 'sed -i s/md542/md5/ firmware-update.sh'

... or use it with the appropriate container name. sed is available inside the deconz-container and therefore no installation is needed.

sed... very sleek. that didn't cross my mind.


Expose op:sample-by function in Java Client API

As task in bugtrack, https://bugtrack.marklogic.com/55089
A sample query as below
xquery version "1.0-ml";
import module namespace op="http://marklogic.com/optic"
at "/MarkLogic/optic.xqy";
op:from-view("opticUnitTest", "musician")
=> op:sample-by(map:map()=>map:with("limit", 2))
=> op:result()
So we can address your issue, please include the following:
Version of MarkLogic Java Client API
See Readme.txt
Version of MarkLogic Server
See admin gui on port 8001 or run xdmp:version() in Query Console - port 8000)
Java version
Run java -version
OS and version
For MAC, run sw_vers.
For Windows, run  systeminfo | findstr /B /C:"OS Name" /C:"OS Version"
For Linux, run cat /etc/os-release and uname -r
Input: Some code to illustrate the problem, preferably in a state that can be independently reproduced on our end
Actual output: What did you observe? What errors did you see? Can you attach the logs? (Java logs, MarkLogic logs)
Expected output: What specifically did you expect to happen?
Alternatives: What else have you tried, actual/expected?

Besides writing a unit test using PlanBuilder.sampleByOptions(), please consider whether it makes sense to add

A PlanBuilderBase.AccessPlanBase.sampleBy() method overload that takes the limit as an int.
A PlanBuilderSubImpl.AccessPlanSubImpl,sampleBy() implementation that constructs the PlanSampleByOptionsImpl and calls the existing method

Thanks, Erik. Will do.

PlanSampleByOptions options = p.sampleByOptions().withLimit(2);
The unit test throws an error, "Server Message: OPTIC-INVALARGS: fn.error(null, 'OPTIC-INVALARGS', 'limit must be a positive number: '+length); -- Invalid arguments: limit must be a positive number: 4"
I found that it errors out at line 2731 of optic-impl.sjs. The number we passed in is treated as a string, not a number. Investigating.

The limit in PlanSampleByOptions is indeed a xs:int, but later changed to String in ExportablePlan.

Proposed changes:
Index: marklogic-client-api/src/main/java/com/marklogic/client/impl/PlanBuilderSubImpl.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
diff --git a/marklogic-client-api/src/main/java/com/marklogic/client/impl/PlanBuilderSubImpl.java b/marklogic-client-api/src/main/java/com/marklogic/client/impl/PlanBuilderSubImpl.java
--- a/marklogic-client-api/src/main/java/com/marklogic/client/impl/PlanBuilderSubImpl.java	(revision b495d4f5a70e8e953f6ba03a82ba74387729aef4)
+++ b/marklogic-client-api/src/main/java/com/marklogic/client/impl/PlanBuilderSubImpl.java	(date<PHONE_NUMBER>496)
@@ -560,13 +560,13 @@
 return mapdef;

}

static Map<String,String> makeMap(PlanSampleByOptions options) {

static Map<String,XsIntVal> makeMap(PlanSampleByOptions options) {
if (options == null) {
return null;
}
XsIntVal limit = options.getLimit();

return (limit == null) ? null : makeMap("limit", limit.toString());

return (limit == null) ? null : makeMap("limit", limit);
}
static Map<String,String> makeMap(PlanSparqlOptions options) {
if (options == null) {
@@ -599,7 +599,15 @@
return map;
}

static BaseTypeImpl.BaseMapImpl asArg(Map<String,String> arg) {

static Map<String, XsIntVal> makeMap(String key, XsIntVal value) {
Map<String, XsIntVal> map = new HashMap<String, XsIntVal>();
if (key != null) {

 map.put(key, value);

}
return map;
}

static BaseTypeImpl.BaseMapImpl asArg(Map<String, ?> arg) {
if (arg == null) {
return null;
}


Increase code coverage

Add spec for Search Projects
Add spec for Donate
Add spec for Header
Improve spec for FAQ

Coverage report shows overall code coverage up to 90%!
BEFORE
81.48% Statements 396/486
71.74% Branches 99/138
74.67% Functions 112/150
82.05% Lines 384/468
AFTER
90.53% Statements 440/486
76.09% Branches 105/138
90% Functions 135/150
90.38% Lines 423/468
Report link: https://lcov-report.kevinashworth.vercel.app/
--
I also cleaned up some the wording and formatting of several spec files

For some reason, vercel is not working for me, so I have published a netlify url for the updated code coverage report:
https://cti-code-coverage-report.netlify.app/


TypeError: Cannot read property 'selectedBackgroundColor' of undefined

hi I have this error after following the example in the Readme
TypeError: Cannot read property 'selectedBackgroundColor' of undefined
SwitchSelector
src/SwitchSelector.tsx:86

Hey, thanks for reporting that issue.
It seems like your initialSelectedIndex prop doesn't match item from your options array at that index.
I've handled this scenario in 114fd2c2acdef694199021f45a899ec30174be7d
Cheers


AVRO-1879: Make conversions field static

I just merged this. Could you close this PR @mwong38? (I forgot to add the note to the commit message to do it.) Thanks!


ZQuery.fromZIO never applies DataSourceAspects

This bit me today when implementing a tracing wrapper for Caliban.
It seems like DataSourceAspects are never executed for ZQueries created via ZQuery.fromZIO, scastie here.
As a caller, this feels a inconsistent since I don't really have a way of knowing how the ZQuery was constructed, and it also means that currently isn't really a way to implement an aspect for ZQueries in the general sense.
I think it's due to the combination of how ZQuery.fromZIO is implemented along with the behaviour of Result.done.
I wonder if an alternative implementation of ZQuery.fromZIO could be to still treat it as a Result.Blocked whose blocking requests are BlockingRequests.empty and have to continuation be the ZIO passed in? I guess it will incur some slight overhead but behave consistently.

A DataSourceAspect transforms one DataSource into another so it is the wrong place to look for transforming a query that does not involve any DataSource at all. However, there could be a QueryAspect that is similar to a ZIOAspect that allows modifying a query more generally. I will take a look at this.

Awesome @adamgfraser! For reference, this is where I ran into it: https://github.com/ghostdogpr/caliban/pull/1616


Towards validating tutorials render correctly on the website

Any changes required to make them do will be made in this PR.

I expected to fix the plots for the files that were broken earlier hence the branch name but after running them locally now (and checking the corresponding PRs) seems like @ablaom has fixed them as well. Thank you for that.
In the commit above I add missing Project.toml and Manifest.toml files for the new credit fraud tutorial.

In the commit above non-code in seven tutorials was modified to let serving pass. This includes exactly two things:

Some @@ were altered (removed) when these tutorials were fixed. I ran the script again after removing them all and their Franklin errors were gone. @ablaom I think we may need to clarify in the README that contributors should ignore them when modifying existing tutorials (or I can easily modify the script to handle fixing them) and one would have to rerun after changing tutorials.
Removing special characters from comments inside functions before a return. An ambiguous error due to Franklin would arise otherwise.

Note that the fact that serving passed doesn't imply that everything will render correctly as code errors are treated as warnings. This is what I will be looking into now.

Data Basics Equivalence Check
Check is done by comparing old and new website side by side for the specific tutorial.

Tutorial Name
Check Results

D0-categorical
Success

D0-dataframe
Success

D0-loading
Success

D0-processing
Need to fix Franklin Warning Failed to precompile Plots. Also had to addCSV.

D0-scitype
Success

A note about the error above is that (most) plots still show successfully but the warning shows as an error in the notebook.

Getting Started Equivalence Check

Tutorial Name
Changes Introduced

A-model-choice
Success

A-fit-predict
Success

A-model-tuning
Plot issue above + RNG issue + UndefVarError: plot not defined for recipe

...

Introduction to Statistical Learning Equivalence Check

Tutorial Name
Changes Introduced

Lab 2
Success with minor RNG issue

Lab 3
Success

Lab 4
Success after typo fix

Lab 5
Success

Lab 6b
Success with likely RNG issues

Lab 8
Success

Lab 9
Success

Lab 10
Success

Tutorial Name
Check Results

EX-telco
Success but actually modified

EX-GLM
Success

EX-airfoil
Success

EX-boston-flux
Success

EX-breastcancer
Success

⚠ EX-horse
Success except for slightly inconsistent conclusions in A baseline model section

EX-housekingcounty
Success

EX-powergen
Success

⚠ EX-wine
Success except for a very minor conclusion in Getting a Baseline section

EX-AMES
Success but may be misunderstanding something as an inconsistency ⚠

⚠ EX-crabs-xgb
Success with a plot-conclusion inconsistency in XGBoost Machine as an exception

⛔ EX-boston-lgbm
Unable to run full tutorial due to NULL library handle

Summary of Checks:

All plots render as expected except for one instance as reported in the last table
All outputs are okay except for some instances where the conclusions didn't quite align with them as reported in the last table
I was unable to serve() LightGBM tutorial, likely due to platform issues, as reported in the last table

I have also added a commit where I have increased the font sizes for some tutorials. Some tutorials had ordinarily-sized and legible text plots so I didn't touch them. Otherwise, I increased font scaling then viewed the tutorial again. I don't always scale with the same number because when plot(machine) is present a smaller font is preferred to prevent text from clashing with the axes.

Take note that plots may appear larger than expect while serving. I wasn't able to solve this by changing the figure size with Plots.jl but was able to solve it by limiting image sizes via CSS (but I didn't push any style changes).

Will say that for me, Franklin's serve() with an empty directory doesn't behave the same as serve() followed by serve(eval_all=true) which is surprising (and took me time to figure out).
Think I am now done with validating the tutorials and plots for all tutorials except for LightGBM.
I will now move on to other PRs related to the navigation bar items or styling.

@EssamWisam Are you able to resolve the conflicts here?

@EssamWisam Are you able to resolve the conflicts here? Or is this PR now redundant?

This is the most important PR on the table xD. I think solving the conflict should be easy. It's just because in other PR we merged already I moved A-ensembles-3 to advanced.

I found some broken links:

But actually as these resources are now quite old, let's just remove them (keeping the preceding link to Telco).

The link to external resources points to a non-existent file. You can find what was planned for this here.
Let's remove "MLJTutorials" from this list, and all other references to it, as it is quite old.

A small annoyance is that switching tabs on the landing page is not permanent, in the sense that going back after following a link always returns you to the "New to Julia?" tab. If this is a lot of work to fix, however, let's just create an issue to flag it for later.

The first link here is broken:

And "top of this page" no longer makes sense. Maybe just "click here".

A bunch of links from the tabs to intro to stats learning are broken. I think there is a spelling mistake (my bad):

("learning" not ".earning")

@ablaom The commits above address all the commends you mentioned. I tried to be cautious while testing so I can merge this directly.


[FEATURE] Add support for headers for ExtensionRestRequest

Is your feature request related to a problem?
Currently, there's no provision to fetch headers from ExtensionRestRequest which is required for various features of Anomaly Detector plugin and for the future.
What solution would you like?
Create

header - To get the value of the header
getAllHeaderValues - To get all values for the header
getHeaders - To get all of the headers and values associated with the headers

These methods are similar to what RestRequest currently has.
What alternatives have you considered?
A clear and concise description of any alternative solutions or features you've considered.
Do you have any additional context?
Add any other context or screenshots about the feature request here.

Note the comment in RestSendToExtensionAction where headers will be passed:
// HERE BE DRAGONS - DO NOT INCLUDE HEADERS
// SEE https://github.com/opensearch-project/OpenSearch/issues/4429
new ExtensionRestRequest(method, path, params, contentType, content, requestIssuerIdentity),

We cannot send the headers unfiltered. In particular we need to remove security-sensitive information such as basic authentication (we do not want to send user/password to extensions).
So yes, we need headers.  No we can't just copy them blindly from the REST request.  Yes this need a lot of eyes on it to make sure we get it right.   Tagging @davidlago @peternied @cwperks @scrawfor99 to provide 8 more eyes on this issue.

Directly linking the issue in the quoted comment above for your clicking ease: https://github.com/opensearch-project/OpenSearch/issues/4429

https://www.invicti.com/blog/web-security/http-security-headers/

https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication

https://www.baeldung.com/java-httpclient-basic-auth

Hi @owaiskazi19, thank you for filing this issue. As @dbwiddis mentioned, there is a lot of complexity that comes into play when you are trying to deal with passing any headers to extensions. I am not sure if there have been discussions elsewhere on GitHub about potential solutions but I don't know that I see an obvious choice. Unfortunately, it comes down to restricting information enough but not too much.
One possibility is to allow for a moving definition of what "too much" is. We could make extension installation come with an explanation of the information which the extension uses. Users would then need to agree or decline to accept that use. Unfortunately, this does not really solve the problem of "what is the right amount" but instead punts it down the road and places the burden of judgement on the end user. It is also somewhat counter-productive to a major idea of extensions which seeks to make the installation of extensions light weight and stress free...
Perhaps you have some thoughts on how you would be interested in seeing these restrictions handled? Your perspective as an extension author would be invaluable.
Thank you.

This sounds like a CORS problem where the admin of the OpenSearch Cluster needs to be empowered to define what headers are permissible. This may be done with different levels of granularity. Maybe by extension or by route + verb?
Access-Control-Allow-Headers is a CORS header used to reply to a client making a pre-flight OPTIONS request with what headers the server permits: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Headers
CORS example with nginx: https://enable-cors.org/server_nginx.html
Tomcat CORS filter: https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CORS_Filter

This sounds like a CORS problem where the admin of the OpenSearch Cluster needs to be empowered to define what headers are permissible.

My first thought was "hey, that sounds like a good idea, let a user configure if they want to pass, say, the Authentication header."   But then I realized "all we need is a hacker or dumb cluster admin and we will suddenly expose username and password information to any extension".
I think there is already some built-in header filtering functionality that can be leveraged, but IMO we should always, without user override, strip the RFC 7235 "Authentication" header, if not others.

@dbwiddis Do we have a full list of headers to block always. Authorization is the header that carries basic auth info and should never be forwarded to an extension. If a user is using curl and misspells Authorization as Authorisation, can we make sure that is not inadvertently forwarded?

Thanks @cwperks @dbwiddis and @scrawfor99 for your valuable inputs. This looks like a big fish in the pond. I will go ahead and close my PR on OpenSearch.

@dbwiddis Do we have a full list of headers to block always? Authorization is the header that carries basic auth info and should never be forwarded to an extension. If a user is making a request and misspells Authorization as Authorisation, can we make sure that is not inadvertently forwarded?

Do we want to use Levenshtein Distance as a filter?  Do I actually get to implement one of those job interview algorithms? :D
Seems a better/safer idea to explicitly define a list of headers we need/allow (possibly make it a configurable setting).  @owaiskazi19 WDYT?

Hi @owaiskazi19, I found 2 areas in the security plugin that relate to HTTP Headers:

When audit logging requests the Authorization header is removed: https://github.com/opensearch-project/security/blob/main/src/main/java/org/opensearch/security/auditlog/impl/AuditMessage.java#L354-L362
REST requests that contain headers starting with _opendistro_security_ are rejected: https://github.com/opensearch-project/security/blob/main/src/main/java/org/opensearch/security/filter/SecurityRestFilter.java#L146-L152

Thanks @cwperks. Looks like for OpenSearch also we are filtering with OPENDISTRO_SECURITY_CONFIG_PREFIX. As @dbwiddis mentioned,  we can define allowList and denyList for the headers then.

Hey @owaiskazi19 I will implement this, can you give me a list of the headers you need for your AD search detector work?

Hey @owaiskazi19 I will implement this, can you give me a list of the headers you need for your AD search detector work?

One such use case I have encountered for SearchDetector is this. Will add more once I start the work for SearchDetector.

@owaiskazi19 I'm still not sure where actual headers are required to be passed from the RestRequest into the ExtensionRestRequest, although I do see some method needs.
The one case you have identified above calls contentOrSourceParamParser() which returns an XContentParser.

That parser is generated from XContentType xContentType = parseContentType(Collections.singletonList(typeParam)); where typeParam = param("source_content_type");

That comes from the URI, like this.
Params are already passed so you should be able to fetch that using something like XContentType.fromMediaType(typeParam)
Looking into the entire RestRequest class, the only place I see headers parsed is here:
    public static XContentType parseContentType(List<String> header) {
        if (header == null || header.isEmpty()) {
            return null;
        } else if (header.size() > 1) {
            throw new IllegalArgumentException("only one Content-Type header should be provided");
        }

That is only called from two places. One is the singleton list generated from the param (not headers) above. The other is the constructor which sets the instance field xContentType based on the "Content-Type" header:
        final XContentType xContentType;
        try {
            xContentType = parseContentType(headers.get("Content-Type"));
        } catch (final IllegalArgumentException e) {
            throw new ContentTypeHeaderException(e);
        }

This instance field value is already included in the ExtensionRestRequest created from the original RestRequest, so the result of that header parsing is also available to you.
So for this particular use case, I don't think you need the headers, and this issue shouldn't be a blocker.
Certainly there is room to implement some of these methods on ExtensionRestRequest and I can work on doing that.  I've wondered if ExtensionRestRequest should extend RestRequest and this seems like a valid reason for why that should be; I think going that way may be the best way to get you the method you need.  WDYT?

I've wondered if ExtensionRestRequest should extend RestRequest

I think this is probably the best path forward.  Here are the constructor needs:
    protected RestRequest(
        NamedXContentRegistry xContentRegistry,
        Map<String, String> params,
        String path,
        Map<String, List<String>> headers,
        HttpRequest httpRequest,
        HttpChannel httpChannel
    ) {

We already pass params and path and some parts of the HttpRequest (we could add the rest, with header filtering).  We could pass the SDKNamedXContentRegistry as well to populate that field new with every request.  And I don't think we need channel.
If we just do a denyList for the headers mentioned above AND an allowlist currently only containing Content-Type but which we can carefully add to, this would be plug-and-play (and reduce the diff even more).

Hey @nassipkali thanks for stepping up!
When I initially implemented Rest Handling on Extensions I used one class (ExtensionRestRequest) for both the transport communication and for the Rest handlers.   This required copying over a bunch of methods, but as this issue points out, we need even more.
So the approach we will be taking is twofold:

Keep the ExtensionRestRequest class as a means of communicating the components of a REST request from Opensearch to the extension
When we receive and deserialize the request, we will instantiate a new RestRequest object using the constructor mentioned in this comment which already has all the needed methods.

So here's a step-by-step:

Modify the ExtensionRestRequest class (on OpenSearch) to include a Map<String, List<String>> headers.  You will add an instance field, add a parameter to the constructor, add a getter, and add processing the map to the writeTo() method and the constructor taking a Streaminput Param.    Please add a comment in the javadoc saying to not include security sensitive information in the headers!
Update the RestSendToExtensionsAction class (On OpenSearch) where it sends the ExtensionRestRequest.   Create a map here to send as a parameter, but do not just copy the RestRequest headers.  For now we only want the Content Type header.
On SDK, update the ExtensionsRestRequestHandler class.  You will be inserting new code at the top of this method:
https://github.com/opensearch-project/opensearch-sdk-java/blob/ded6ed00cd06cb4d710a356d877e31a346925660/src/main/java/org/opensearch/sdk/handlers/ExtensionsRestRequestHandler.java#L51

You will use the getters on the parameter ExtensionRestRequest request to retrieve the information that was sent in steps 1 and 2 above, and you will create a new instance of RestRequest from OpenSearch using this constructor:
    protected RestRequest(
        NamedXContentRegistry xContentRegistry,
        Map<String, String> params,
        String path,
        Map<String, List<String>> headers,
        HttpRequest httpRequest,
        HttpChannel httpChannel
    ) {

The params and path are already being sent, and you will be adding headers in the first steps above, just use the getters on the request.
For the xContentRegistry, you will change the constructor to add a parameter SDKNamedXContentRegistry to save as a private instance field, and populate this parameter in the RestRequest using the getRegistry()` method on it.
You won't use the httpChannel, so you can leave that null.
That leaves the HttpRequest which is an interface.  You'll need to have an implementing class that implements the required methods.  I haven't exactly figured out how I want to do this yet, so feel free to try something yourself here.

We may want to create a separate implementing class in the SDK, like SDKHttpRequest implements HttpRequest).  Currently we have implemented method()andcontent()(seeExtensionRestRequest).  For the other things, you can either return sensible defaults (we don't need strictCookies()) or do further modifications to the serialized info you're sending with the ExtensionRestRequest` such as  protocol version.

This should be enough info to get started, let me know if you have any questions!

Oh, almost forgot.... after you do the above you'll replace the parameter in this line with the new request you created:
https://github.com/opensearch-project/opensearch-sdk-java/blob/ded6ed00cd06cb4d710a356d877e31a346925660/src/main/java/org/opensearch/sdk/handlers/ExtensionsRestRequestHandler.java#L66
And you'll be replacing the handling in HelloWorld example to the new class.  One thing that will definitely change is the xContentParser will be simplified to match the way it currently is done in any of the OpenSearch classes extending BaseRestHandler implementing RestHandler.

@dbwiddis Is 430 issue connected to this issue? Do we need to sync our work on #430 and #431 issues

@nassipkali no, 430 will be dealing with work in the SDKClient.   The only interaction would be in actual REST handler implementation where when processing a RestRequest you used some information in it to send to client.execute().

IF you want do do an initial PR just as far as the first comment, and a second PR doing the actual implementation, that would also be welcome.

@nassipkali I have opened draft PRs on OpenSearch and SDK for you to refer and get started. The work is not fully finished but the changes will help to get moving and then you can create new PRs or push it to my existing PRs. Anyway you like

@dbwiddis I'm stuck on the theoretical part of the problem. I think I'm missing some technical details on how I should filter headers.

@dbwiddis @owaiskazi19 how denyList and allowList should be configured? Is it predefined or it should be pass as params or read from config file

We don't have them yet.  They can be defined however you want.  For now, and for simplicity, it's probably easier to just leave a TODO comment about implementing them later, and just create a new headers object from scratch, containing only the value of the Content Type header.

@dbwiddis I'm stuck on the theoretical part of the problem. I think I'm missing some technical details on how I should filter headers.

The headers are in a Map<String, List<String>> that you could retrieve via getHeaders().  You could iterate over the entryset and only keep the one matching the key "Content Type".
Alternately, since we are only doing that one header, you could call List<String> getAllHeaderValues(String name) with the content type string as the name, get those header values, and insert it into the new map you are creating.

Optionally, if you wanted an allowlist variable, you could do List.of("Content Type") and do a denylist List.of("Authentication").   Then you'd process the map entries and filter something like this (typing from memory, this may not compile, just a suggestion):
restRequest.getHeaders().entrySet().stream()
    .filter(e -> !denyList.contains(e.getKey())
    .filter(e -> allowList.contains("*") || allowlist.contains(e.getKey()))
    .collect(Collectors.toMap());

Optionally, if you wanted an allowlist variable, you could do List.of("Content Type") and do a denylist List.of("Authentication"). Then you'd process the map entries and filter something like this (typing from memory, this may not compile, just a suggestion):
restRequest.getHeaders().entrySet().stream()
    .filter(e -> !denyList.contains(e.getKey())
    .filter(e -> allowList.contains("*") || allowlist.contains(e.getKey()))
    .collect(Collectors.toMap());

Thanks, I will try something like this.

Also when you get to serializing that headers HashMap, I found an example in OpenSearch's SimulateIndexTemplateResponse class on the overlappingTemplates variable that is probably a good example to follow for your writeTo() and streaminput constructor additions.
For input:
            int overlappingTemplatesCount = in.readInt();
            overlappingTemplates = new HashMap<>(overlappingTemplatesCount, 1L);
            for (int i = 0; i < overlappingTemplatesCount; i++) {
                String templateName = in.readString();
                overlappingTemplates.put(templateName, in.readStringList());
            }

and writeTo:
            out.writeInt(overlappingTemplates.size());
            for (Map.Entry<String, List<String>> entry : overlappingTemplates.entrySet()) {
                out.writeString(entry.getKey());
                out.writeStringCollection(entry.getValue());
            }

Also note I just looked them up and fixed the actual headers we want to allow/block:

allowlist: List.of("Content-Type")
denylist: List.of("Authorization", "Proxy-Authorization")

Hey @nassipkali I'm going to take on the 2nd part of this issue (creating the new RestRequest and integrating it into SDK) to take some of the time pressure off you to complete the first part (copying the headers over in the ExtensionRestRequest).  That will allow us to move forward with some dependent work, and once your work is done it will plug right in.

Hey @nassipkali I'm going to take on the 2nd part of this issue (creating the new RestRequest and integrating it into SDK) to take some of the time pressure off you to complete the first part (copying the headers over in the ExtensionRestRequest). That will allow us to move forward with some dependent work, and once your work is done it will plug right in.

Ok then I send pull request to OpenSearch

Hey @nassipkali thanks for stepping up!
When I initially implemented Rest Handling on Extensions I used one class (ExtensionRestRequest) for both the transport communication and for the Rest handlers. This required copying over a bunch of methods, but as this issue points out, we need even more.
So the approach we will be taking is twofold:
1. Keep the `ExtensionRestRequest` class as a means of communicating the components of a REST request from Opensearch to the extension

2. When we receive and deserialize the request, we will instantiate a new `RestRequest` object using the constructor mentioned [in this comment](https://github.com/opensearch-project/opensearch-sdk-java/issues/431#issuecomment-1476973096) which already has all the needed methods.

So here's a step-by-step:
1. Modify the [`ExtensionRestRequest`](https://github.com/opensearch-project/OpenSearch/blob/f40fa82e3667825fd0ba8d4bb17b6959ff7cc4f1/server/src/main/java/org/opensearch/extensions/rest/ExtensionRestRequest.java#L37) class (on OpenSearch) to include a `Map<String, List<String>> headers`.  You will add an instance field, add a parameter to the constructor, add a getter, and add processing the map to the `writeTo()` method and the constructor taking a Streaminput Param.    Please add a comment in the javadoc saying to not include security sensitive information in the headers!

2. Update the [`RestSendToExtensionsAction`](https://github.com/opensearch-project/OpenSearch/blob/f40fa82e3667825fd0ba8d4bb17b6959ff7cc4f1/server/src/main/java/org/opensearch/extensions/rest/RestSendToExtensionAction.java#L171-L173) class (On OpenSearch) where it sends the `ExtensionRestRequest`.   Create a map here to send as a parameter, but do not just copy the RestRequest headers.  For now we only want the `Content Type` header.

3. On SDK, update the [ExtensionsRestRequestHandler](https://github.com/opensearch-project/opensearch-sdk-java/blob/main/src/main/java/org/opensearch/sdk/handlers/ExtensionsRestRequestHandler.java) class.  You will be inserting new code at the top of this method:
   https://github.com/opensearch-project/opensearch-sdk-java/blob/ded6ed00cd06cb4d710a356d877e31a346925660/src/main/java/org/opensearch/sdk/handlers/ExtensionsRestRequestHandler.java#L51

You will use the getters on the parameter ExtensionRestRequest request to retrieve the information that was sent in steps 1 and 2 above, and you will create a new instance of RestRequest from OpenSearch using this constructor:
    protected RestRequest(
        NamedXContentRegistry xContentRegistry,
        Map<String, String> params,
        String path,
        Map<String, List<String>> headers,
        HttpRequest httpRequest,
        HttpChannel httpChannel
    ) {

1. The `params` and `path` are already being sent, and you will be adding headers in the first steps above, just use the getters on the request.

2. For the xContentRegistry, you will change [the constructor](https://github.com/opensearch-project/opensearch-sdk-java/blob/ded6ed00cd06cb4d710a356d877e31a346925660/src/main/java/org/opensearch/sdk/handlers/ExtensionsRestRequestHandler.java#L41) to add a parameter `SDKNamedXContentRegistry` to save as a private instance field, and populate this parameter in the `RestRequest using the `getRegistry()` method on it.

3. You won't use the httpChannel, so you can leave that null.

4. That leaves the `HttpRequest` which is an interface.  You'll need to have an implementing class that implements the required methods.  I haven't exactly figured out how I want to do this yet, so feel free to try something yourself here.

   * We may want to create a separate implementing class in the SDK, like `SDKHttpRequest implements HttpRequest`).  Currently we have implemented `method()` and `content()` (see `ExtensionRestRequest`).  For the other things, you can either return sensible defaults (we don't need `strictCookies()`) or do further modifications to the serialized info you're sending with the `ExtensionRestRequest` such as  protocol version.

This should be enough info to get started, let me know if you have any questions!

How I can use constructor of RestRequest if it has protected modifier?

How I can use constructor of RestRequest if it has protected modifier?

Create a subclass!  We have to do the same thing for HttpRequest which is an interface.
Take a look at #602 where there's a separate class implementing that interface.  You'll probably want to do the same for a class which extends RestRequest and you can call super() with those arguments.
As a subclass it will still allow existing methods acting on the superclass.

Actually... better idea.  Just create the SDKHttpRequest similar to (or using the code in) #602 and then pass it as a parameter to the static constructor for the RestRequest:
public static RestRequest request(NamedXContentRegistry xContentRegistry, HttpRequest httpRequest, HttpChannel httpChannel)

And to be clear on the dividing line between our work, I will expect you to create that RestRequest object in the ExtensionRestRequestHandler class handleRestExecuteOnExtensionRequest() method but do nothing with it (yet).  I will take over changing the class param in the line ExtensionRestResponse response = restHandler.handleRequest(request); and change from the existing request (the ExtensionRestRequest) to the "new" request you are creating, along with any follow-on integration.

I spent a few minutes seeing what would happen if I passed around the RestRequest object where we currently pass around ExtensionRestRequest and found somewhat of a blocker.  We've already used that class in our ExtensionRestResponse class, where we've passed around the consumed parameters.  And that class has been released in some OpenSearch 2.x releases as API.  Even though nobody else has probably been using them, we're possibly breaking BWC guarantees here.
Also looking at that class there are a lot of things we just don't need.   So while I still think we need that object, I think we can just have an object wrapped inside the ExtensionRestRequest object that we can delegate method calls to.  That will keep the same API we've been using and we can just add a few more methods as we need them.  We can just add a setRestRequest() method to insert the new class we're creating into the ExtensionRestRequest.
Also since we're not passing it around anywhere, we can just use an anonymous subclass, like this code in ExtensionsRestRequestHandler:
public RestExecuteOnExtensionResponse handleRestExecuteOnExtensionRequest(final ExtensionRestRequest request) {

ExtensionRestHandler restHandler = extensionRestPathRegistry.getHandler(request.method(), request.path());
if (restHandler == null) {
    return new RestExecuteOnExtensionResponse(
        NOT_FOUND,
        TEXT_CONTENT_TYPE,
        String.join(" ", "No handler for", request.method().name(), request.path()).getBytes(UTF_8),
        emptyMap(),
        emptyList(),
        false
    );
}

request.setRestRequest(RestRequest.request(
    sdkXContentRegistry.getRegistry(),
    new HttpRequest() {

        @Override
        public Method method() {
            return request.method();
        }

        @Override
        public String uri() {
            // for now, path strips query off uri but probably want to pass the whole uri
            return request.path();
        }

        @Override
        public BytesReference content() {
            return request.content();
        }

        @Override
        public Map<String, List<String>> getHeaders() {
            // for now, once we have a header object can use that
            return Map.of("Content-Type", List.of(request.getXContentType().mediaType()));
        }

        @Override
        public List<String> strictCookies() {
            return Collections.emptyList();
        }

        @Override
        public HttpVersion protocolVersion() {
            // This is two integers, should add to the request
            return null;
        }

        @Override
        public HttpRequest removeHeader(String header) {
            // we don't use
            return null;
        }

        @Override
        public HttpResponse createResponse(RestStatus status, BytesReference content) {
            return null;
        }

        @Override
        public Exception getInboundException() {
            // we don't use
            return null;
        }

        @Override
        public void release() {}

        @Override
        public HttpRequest releaseAndCopy() {
            // we don't use
            return null;
        }
    },
    null
);

And after playing with this a bit more, the best option is not to put this in the request handler, but in the StreamInput constructor of the ExtensionRestRequest object where we have access to all these things.

(We still need to set the xContentRegistry in the handler.)

And after going around in circles I'm back to realizing changing the ExtensionRestRequest is already doing the same BWC breaking stuff that I was trying to avoid, and making it a lot more complicated.   SO back to the original plan of a new SDKRestContent object.

And after going around in circles I'm back to realizing changing the ExtensionRestRequest is already doing the same BWC breaking stuff that I was trying to avoid, and making it a lot more complicated. SO back to the original plan of a new SDKRestContent object.

What does SDKRestContent?

Typo, or lack of coffee.  I was still thinking xContentRegistry.  WE need a RestRequest (or subclass) object and we can construct it using a SDKHttpRequest which is the direction you are already going.

Fixed in #643 and companion PRs.


Added slash command and base prompt

Added feature: #2

[x] Migrate slash command code files from the proof of concept Embellisher App to current repo.
[x] Test the prompts and ideas experimented on Groq - Fast AI Inference.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Sandeep Pillai seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Sandeep Pillai seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Unthemed home search bar

The search bar in default Firefox home is unthemed, is this intended?

Looks like this is no longer an issue; feel free to re-open/open a new issue if it is.
Thanks


Roll Flutter Engine from ace31a8eaea4 to 7d47532bb56f (1 revision)

https://github.com/flutter/engine/compare/ace31a8eaea4...7d47532bb56f
2023-10-17<EMAIL_ADDRESS>Roll Dart SDK from 7d0a805e4ee1 to 82c073d657eb (1 revision) (flutter/engine#46995)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC jimgraham@google.com,rmistry<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose
To report a problem with the AutoRoller itself, please file a bug:
https://issues.skia.org/issues/new?component=1389291&template=1850622
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

Commit queue failed; closing this roll.


docs: Added instructions on configuring Superset SECRET_KEY

SUMMARY
Added alternative instructions on setting SECRET_KEY via environment variables.
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Required feature flags:
[x] Changes UI
[ ] Includes DB Migration (follow approval process in SIP-59)

[ ] Migration is atomic, supports rollback & is backwards-compatible
[ ] Confirm DB migration upgrade and downgrade tested
[ ] Runtime estimates and downtime expectations provided

[ ] Introduces new feature or API
[ ] Removes existing feature or API

Hello, thanks for the PR and showing the before/after screenshots.  Can you please explain what the advantage to this is / what the improvement is here?  It seems like another way of adding the value to superset_config.py, which is already covered, and I'm not sure this will persist through the machine restarting.

@sfirke Hello, many users have encountered the error below(ex: https://github.com/apache/superset/discussions/23598). While the initial 'Configuring Superset' section does touch upon setting the SUPERSET_SECRET_KEY environment variable, I believe providing this explicit alternative would make the local setup process more straightforward for beginners. Additionally, I realize this documentation update doesn't directly address the issues some users face with superset re-encrypt-secrets and the PREVIOUS_SECRET_KEY setting. However, I felt this change was a step towards simplifying the initial setup for new users.

SUPERSET_SECRET_KEY environment variable is already supported https://github.com/apache/superset/blob/master/superset/config.py#L184
so those additional imports are not required. Just defining the environment variable is enough.

@mdeshmu Thank you for the feedback. I've made the suggested update. Tweaked it to include macOS

@sfirke please review.


Requesting Translator Badge

User ID
U-SlyTheFloof

I don't currently see any active contributions under your account here: https://github.com/Yellow-Dog-Man/Locale/graphs/contributors


Build RPMs for the LDMS sampler on surrogate system A

estimate 3

Done criteria:

write a spec file for the surrogate system
validate operation
share and present to collaborators

http://mcfly.ra.intel.com/~cmcantal/ovis-geopm-sampler-4.3.8-1.src.rpm
http://mcfly.ra.intel.com/~cmcantal/ovis-geopm-sampler-4.3.8-1.x86_64.rpm


Rebuild for GDAL3

Checklist

[X] Used a fork of the feedstock to propose changes
[X] Bumped the build number (if the version is unchanged)
[X] Reset the build number to 0 (if the version changed)
[X] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[X] Ensured the license file is being packaged.

@conda-forge-admin, please rerender

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Hi! This is the friendly automated conda-forge-webservice.
I tried to re-render for you but ran into some issues, please ping conda-forge/core for further assistance.

Hi! This is the friendly automated conda-forge-webservice.
I tried to re-render for you but ran into some issues, please ping conda-forge/core for further assistance.

@ocefpaf @leouieda This PR rebuilds 5.4.5 with gdal3.
I updated the build number and also added libblas, libcblas and liblapack to the runtime dependency list. This PR will close #77.


improve process state management

motivation: reports on hang process (mostly tests)
changes:

refactor Process to use a state machine to track the process execution state
replace use of DispatchQueue with Locks to protect state

rdar://76087764

@swift-ci test

@swift-ci please test

@abertelrud thanks for the review, amended


Add tests in path_provider and url_launcher plugins

some missing copyright statements

Thanks. Could you please have another quick look?


Limit video recording time

Is there a way to limit video recording duration?

cameraPicker.shouldGeneratePreviewImages(true);
Bundle extras = new Bundle();
// Set the duration of the video
extras.putInt(MediaStore.EXTRA_DURATION_LIMIT, 5);
cameraPicker.setExtras(extras);

It seems not working for the Oreo version. I've tested with OnePlus 3T and it's not working for me.
Could you please suggest any solution for this?
Thanks in advance!


default snackbar height is too low

It's 20px and it looks like this

and is hardly readable.

actually it looks like the problem is with box-sizing


Ansible: how to expose CR status condition in metrics?

Type of question
how to implement a specific feature
Question
I can see there are some built in metrics endpoints but they provide some overall counts only (like: ansible_operator_reconciles_count or controller_runtime_reconcile_errors_total).
But Is there any way to expose metrics which would allow to quantify how many CRs in Status Condition True|False|Unknown? I think this is sort of a standard as per:
https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties
If we have it as part of the metric label together with CR name and namespace, then one could easily monitor the situation when CR changes status to False|Unknown for example.

Hey Guys, any thoughts on this one?

Disclaimer: not an authoritative source when it comes to controller metrics. I have only tied into the work that @lilic had done to expose custom resource metrics (https://github.com/operator-framework/operator-sdk/pull/1277) for Ansible based operators specifically https://github.com/operator-framework/operator-sdk/pull/1723 and have looked at the metrics provided by controller-runtime.
Short answer: No. I do not believe that this is currently possible for operator-sdk based operators in general; this issue isn't specific to Ansible.
It looks like kube-state-metrics does something similar for deployments https://github.com/kubernetes/kube-state-metrics/pull/889 but handling this generically for custom resources would probably take some investigation.

Thanks for checking this. I think it would be a great feature to have :)

Another possible route for having a feature like this would be the hybrid operator approach that we're considering.
Basically, the idea is that we would work toward making the Ansible (and Helm) operator Go code more reusable and extensible. Then, for example, folks would be able to instantiate an Ansible controller in a Go operator and add custom code to support this kind of thing.


How can highlight specific lines in code blocks?

What version of starlight are you using?
latest
What is your idea?
The current version of Starlight doesn't seem to highlight specific lines in a code block as the Astro documentation does. For example:
```json title="package.json" del={2} ins={3} ins="astro check && tsc --noEmit && "
  "scripts": {
    "build": "astro build",
    "build": "astro check && tsc --noEmit && astro build",
  },
```

Is this because we are waiting for the integration of expressive-code into Starlight? #742
Why is this feature necessary?
I wanna to make my documentation be more readable.
Do you have examples of this feature in other projects?
No response
Participation

[ ] I am willing to submit a pull request for this issue.

Is this because we are waiting for the integration of expressive-code into Starlight? #742

Yes, the Astro documentation is already using Expressive Code which supports markers through @expressive-code/plugin-text-markers.
You can even preview it yourself already in the deploy preview of #742, e.g. this page.


Add carousel options

I like the pic, but think it needs lexi in it also so I will send another to you.  Can we have it change pics as it fades out and another one appears?
I just sent  a pic of all three of us that may work.  Maybe not having the schedule now on the Carousel pic?

I will send you the video of facebook of the eyes opening for carousel.  What do you think about music playing also?  Livis idea......there's a song by Demi Lavato....."What's wrong with being confident? " I think would be really cool.

I am going to put the eyes opening thing on there...because you said to. But I can tell you now that will scare the living shit about of about 35% of the people who come to your site at the size it will be in the carousel :)


[ Feature ] Deattachable start

Any intention to add more functionalities like Deattachable start to this great extention
I really think it would be an improvement

@Sharaf5 I'm not using currently this extension, that is the reason why I'm not adding new features to this extension.
However, I will be happy to merge your pull request if you have willingness to submit one.

I have never been good in TS however if I could I would happily do

@Sharaf5 could you explain me what is "deattachable start"? Probably I could quickly implement it for you.

@Sharaf5 Is it the same thing as "headless" mode?

Detachable start is the combination of the normal start and headless start. When you close the VirtualBox VM window, one more option is available – Continue running in the background. You can close the VirtualBox VM window without interrupting the VM


Some Grafana Dashboards on Prometheus Operator 0.34.0 don't have proper expressions to read Pod Metrics

What happened?
Some Grafana Dashboards on Prometheus Operator 0.34.0 don't have proper expressions to read Pod Metrics.  In example, the "Kubernetes / Compute Resources / Pod" Dashboard, has this PromQL query for reporting the CPU usage per Pod:
sum(node_namespace_pod_container:container_cpu_usage_seconds_total:sum_rate{namespace="$namespace", pod="$pod", container!="POD", cluster="$cluster"}) by (container)
The issue is that the labels pod and container are being exposed by Prometheus, for that specific metric as pod_name and container_name .
This discrepancy is recurrent among other PromQL queries in this Dashboard as well as other Grafana dashboards.
Did you expect to see some different?
I'd expect the Grafana Dashboards to be aligned with the Prometheus K8S metrics being exposed by the cluster.
How to reproduce it (as minimally and precisely as possible):
Environment

Prometheus Operator version:

✘    ~/gumgum/eks-ocean-cluster/helm   OPS-4688 ●  kubectl -n monitor describe deployment prometheus-operator
Name:                   prometheus-operator-grafana
Namespace:              monitor
CreationTimestamp:      Wed, 22 Jan 2020 20:52:26 -0500
Labels:                 app=grafana
chart=grafana-4.3.2
heritage=Helm
release=prometheus-operator
Annotations:            deployment.kubernetes.io/revision: 1
Selector:               app=grafana,release=prometheus-operator
Replicas:               1 desired | 1 updated | 1 total | 1 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
Labels:           app=grafana
release=prometheus-operator
Annotations:      checksum/config: 0b368b53e79684321f3b8139fc47595e7d12974c73c6e6be7e0ccadac7e9e5d3
checksum/dashboards-json-config: 01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b
checksum/sc-dashboard-provider-config: b976534c72bafb252c3d936056e8dccf7b552ab628ccff86b141887ad386394d
checksum/secret: 339b072967008a602b19fd54f51dab24607173afbc2572b9fc6ab8c8bfdc3478
Service Account:  prometheus-operator-grafana
Init Containers:
grafana-sc-datasources:
Image:      kiwigrid/k8s-sidecar:0.1.20
Port:
Host Port:
Environment:
METHOD:    LIST
LABEL:     grafana_datasource
FOLDER:    /etc/grafana/provisioning/datasources
RESOURCE:  both
Mounts:
/etc/grafana/provisioning/datasources from sc-datasources-volume (rw)
Containers:
grafana-sc-dashboard:
Image:      kiwigrid/k8s-sidecar:0.1.20
Port:
Host Port:
Environment:
LABEL:     grafana_dashboard
FOLDER:    /tmp/dashboards
RESOURCE:  both
Mounts:
/tmp/dashboards from sc-dashboard-volume (rw)
grafana:
Image:       grafana/grafana:6.5.2
Ports:       80/TCP, 3000/TCP
Host Ports:  0/TCP, 0/TCP
Liveness:    http-get http://:3000/api/health delay=60s timeout=30s period=10s #success=1 #failure=10
Readiness:   http-get http://:3000/api/health delay=0s timeout=1s period=10s #success=1 #failure=3
Environment:
GF_SECURITY_ADMIN_USER:      <set to the key 'admin-user' in secret 'prometheus-operator-grafana'>      Optional: false
GF_SECURITY_ADMIN_PASSWORD:  <set to the key 'admin-password' in secret 'prometheus-operator-grafana'>  Optional: false
Mounts:
/etc/grafana/grafana.ini from config (rw,path="grafana.ini")
/etc/grafana/provisioning/dashboards/sc-dashboardproviders.yaml from sc-dashboard-provider (rw,path="provider.yaml")
/etc/grafana/provisioning/datasources from sc-datasources-volume (rw)
/tmp/dashboards from sc-dashboard-volume (rw)
/var/lib/grafana from storage (rw)
Volumes:
config:
Type:      ConfigMap (a volume populated by a ConfigMap)
Name:      prometheus-operator-grafana
Optional:  false
storage:
Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
Medium:
SizeLimit:
sc-dashboard-volume:
Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
Medium:
SizeLimit:
sc-dashboard-provider:
Type:      ConfigMap (a volume populated by a ConfigMap)
Name:      prometheus-operator-grafana-config-dashboards
Optional:  false
sc-datasources-volume:
Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
Medium:
SizeLimit:
Conditions:
Type           Status  Reason

Available      True    MinimumReplicasAvailable
Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  prometheus-operator-grafana-64d79d584f (1/1 replicas created)
NewReplicaSet:
Events:
Name:                   prometheus-operator-kube-state-metrics
Namespace:              monitor
CreationTimestamp:      Wed, 22 Jan 2020 20:52:26 -0500
Labels:                 app.kubernetes.io/instance=prometheus-operator
app.kubernetes.io/managed-by=Helm
app.kubernetes.io/name=kube-state-metrics
helm.sh/chart=kube-state-metrics-2.6.2
Annotations:            deployment.kubernetes.io/revision: 1
Selector:               app.kubernetes.io/name=kube-state-metrics
Replicas:               1 desired | 1 updated | 1 total | 1 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
Labels:           app.kubernetes.io/instance=prometheus-operator
app.kubernetes.io/name=kube-state-metrics
Service Account:  prometheus-operator-kube-state-metrics
Containers:
kube-state-metrics:
Image:      quay.io/coreos/kube-state-metrics:v1.9.2
Port:       8080/TCP
Host Port:  0/TCP
Args:
--collectors=certificatesigningrequests
--collectors=configmaps
--collectors=cronjobs
--collectors=daemonsets
--collectors=deployments
--collectors=endpoints
--collectors=horizontalpodautoscalers
--collectors=ingresses
--collectors=jobs
--collectors=limitranges
--collectors=namespaces
--collectors=nodes
--collectors=persistentvolumeclaims
--collectors=persistentvolumes
--collectors=poddisruptionbudgets
--collectors=pods
--collectors=replicasets
--collectors=replicationcontrollers
--collectors=resourcequotas
--collectors=secrets
--collectors=services
--collectors=statefulsets
--collectors=storageclasses
Liveness:     http-get http://:8080/healthz delay=5s timeout=5s period=10s #success=1 #failure=3
Readiness:    http-get http://:8080/ delay=5s timeout=5s period=10s #success=1 #failure=3
Environment:
Mounts:
Volumes:
Conditions:
Type           Status  Reason

Available      True    MinimumReplicasAvailable
Progressing    True    NewReplicaSetAvailable
OldReplicaSets:
NewReplicaSet:   prometheus-operator-kube-state-metrics-545d8dfdc (1/1 replicas created)
Events:
Name:                   prometheus-operator-operator
Namespace:              monitor
CreationTimestamp:      Wed, 22 Jan 2020 20:52:26 -0500
Labels:                 app=prometheus-operator-operator
chart=prometheus-operator-8.5.13
heritage=Helm
release=prometheus-operator
Annotations:            deployment.kubernetes.io/revision: 1
Selector:               app=prometheus-operator-operator,release=prometheus-operator
Replicas:               1 desired | 1 updated | 1 total | 1 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
Labels:           app=prometheus-operator-operator
chart=prometheus-operator-8.5.13
heritage=Helm
release=prometheus-operator
Service Account:  prometheus-operator-operator
Containers:
prometheus-operator:
Image:      quay.io/coreos/prometheus-operator:v0.34.0
Port:       8080/TCP
Host Port:  0/TCP
Args:
--kubelet-service=kube-system/prometheus-operator-kubelet
--logtostderr=true
--localhost=<IP_ADDRESS>
--prometheus-config-reloader=quay.io/coreos/prometheus-config-reloader:v0.34.0
--config-reloader-image=quay.io/coreos/configmap-reload:v0.0.1
--config-reloader-cpu=100m
--config-reloader-memory=25Mi
Environment:
Mounts:
tls-proxy:
Image:      squareup/ghostunnel:v1.4.1
Port:       8443/TCP
Host Port:  0/TCP
Args:
server
--listen=:8443
--target=<IP_ADDRESS>:8080
--key=cert/key
--cert=cert/cert
--disable-authentication
Environment:
Mounts:
/cert from tls-proxy-secret (ro)
Volumes:
tls-proxy-secret:
Type:        Secret (a volume populated by a Secret)
SecretName:  prometheus-operator-admission
Optional:    false
Conditions:
Type           Status  Reason

Available      True    MinimumReplicasAvailable
Progressing    True    NewReplicaSetAvailable
OldReplicaSets:
NewReplicaSet:   prometheus-operator-operator-66c95855d6 (1/1 replicas created)
Events:
 ~/gumgum/eks-ocean-cluster/helm   OPS-4688 ● 

Kubernetes version information:

v1.14.9-eks-c0eccc

Kubernetes cluster kind:

AWS EKS

Manifests:

insert manifests relevant to the issue

Prometheus Operator Logs:

insert Prometheus Operator logs relevant to the issue here

Anything else we need to know?:

Any progress with this? Anyone figure out a quick solution until this is resolved?

Presumably everyone here is talking about kube-prometheus, as we're getting a lot of traffic about kube-prometheus issues on the prometheus-operator repository I'm going to close this here as it's causing confusion about the separation of the two projects.
Please open a new issue in the other repository with the full details of which kubernetes version, and which kube-prometheus version you are using.


Various post_backdrop* benchmarks have regressed.

No obvious commit. See, for example, post_backdrop_perf_filter_ios_timeline_summary_90th_percentile_frame_rasterizer_time_millis.
I can't seem to get archived benchmarks for these to find out when this started; the dashboard is hanging.

I'm not sure this should be a today issue as I don't see evidence that performance actually regressed. The benchmark has been performing similarly since December 16th and it looks suspiciously like it wasn't running before then as the time as the graph just shows up as 0ms. Given that I propose removing the TODAY tag. We should still fix the benchmark or fix the expected render time for the benchmark but it shouldn't block a release.

Seems like these tests were added on Dec 13 by PR https://github.com/flutter/flutter/pull/46924. I propose to remove the TODAY tag and instead set a baseline.

Sounds good to me. Let's do that.

@flar : this might be caused by the issue that you're trying to fix in https://github.com/flutter/engine/pull/16175. Nevertheless, I think the CPU/GPU usages should be the ones that we're interested in for those post_backdrop* tests. Shall we simply archive the non CPU/GPU metrics, and close this regression?

We're missing values for recent runs of all of the post_backdrop_* issues at this point, so I"m leaving this open until we know more.

All of the benchmark data for these benchmarks appears to be missing now - even their history. Should that be a separate (possibly TODAY) issue?

@flar : yes, please see https://github.com/flutter/flutter/issues/52692

Looks like #52692 is closed, if @flar wants to have another look. Thanks, all!

Looks like we're missing data again, although we weren't last night when I did a sweep for regressions. @liyuqian, any thoughts here?

https://github.com/flutter/flutter/pull/50367 disabled the test. @flar : would you like to add the test back without using gauge's CPU/GPU measurement?

Triage: The test was disabled and the PR that disabled the test linked to https://github.com/flutter/flutter/issues/45435 as a tracking item for re-enabling measurement of this this kind. Closing this issue.

My concern would be that the goal of https://github.com/flutter/flutter/issues/45435 is not "to enable this benchnmark", it is to introduce a new tool. When that tool is introduced, then this benchmark will become viable again. There is currently no direct issue which is trackable that says "when the tool is complete, reenable this benchmark". This issue was being left open to track that, but perhaps we need an explicit "benchmark X was disabled due to lack of a tool, reenable it when issue N is fixed" issue?

Fair point. I filed https://github.com/flutter/flutter/issues/59238 to track that work item specifically.


vui ui command results in "Error: EISDIR: illegal operation on a directory, read"

Version
3.0.0-rc.7
Node and OS info
Node v10.6.0, NPM v6.1.0, Windows 10
Steps to reproduce
Upgrade to Vue cli 3.0.0-rc.7 from rc.3.  Run the command > vue ui
What is expected?
No error - ui displayed
What is actually happening?
An error is shown in the console, e.g.
λ vue ui
🚀  Starting GUI...
ERROR  Error: EISDIR: illegal operation on a directory, read
Error: EISDIR: illegal operation on a directory, read
at Object.readSync (fs.js:498:3)
at tryReadSync (fs.js:337:20)
at Object.readFileSync (fs.js:374:19)
...

Tried to upgrade to latest RC

Please check existing issues first, this one is at the top of the closed issues...
Duplicate of #1961