Cognitive Realm Layers

Is your feature request related to a problem? Please describe.
The cognitive realm is an important layer of reality in the Cosmere that certain abilities allow access to.
Describe the solution you'd like
The cognitive realm should be a map layer.  "travelling to" or "visibility" of the cognitive realm just means taking the token into the related location in the Shadesmar layer upon a command/button press.
Describe alternatives you've considered
None
Version
0.1.1
Additional context
n/a
Checklist:

[X] I have searched the existing issues to ensure this feature has not already been requested.

Is this going to require a secondary map image for every scene? or is there a proposed place holder for any maps that don't have shadesmar?  An inverter of some sort? especially with relation to the sea of beads in Stormlight.

I want to give some push back on this idea from three points:

It will bloat GM prep, every map suddenly becomes two maps if you want to use the feature (even if there's only a couple of things in it)
This is fundamentally not how layers work in foundry scenes and is not something trivial to implement. Different object types are on different canvas layers (tokens on the tokens layer, background on the background layer, etc.). What you want you want is essentially a second layer stack beside the first.
The cognitive realm is a cosmere concept and doesn't necessarily translate to the generic plotweaver system. Which means we'd have to do a generic implementation, which would probably be a nightmare.

If a GM needs to have an actual scene representation of the cognitive realm they should just make a scene.

Regarding GM prep, every map will just have basically the same background for shadesmar.  What I'm suggesting is reducing prep by showing soul lights where tokens stand and shadows of spren in the physical realm that are visible in shadesmar even when they are not in the physical realm.

The plotweaver system isn't defined enough yet to say whether this would be required or not.  I accept that it's not likely to be required for it though

Another option would be to have a new "roof" type for shadesmar, then a practitioner could toggle their vision to see a part of that roof tile, and all tokens would affect it

The actual end goal of this request needs to be clarified, rather than just a proposed solution. As stanavdb previously stated, adding a “cognitive layer” isn’t feasible.  While Foundry may have some additional capabilities over playing on a physical tabletop, anything asked of Foundry still needs an analogue to the ttRPG version of the game, and this is very vague.
So what is the specific end result that is desired? If someone needs to travel to the Cognitive realm, the token can be moved to a new scene manually or by an active tile effect (a tool within Foundry). Does a character just need to be able to see hidden or invisible things? A simple macro can be used to toggle a token’s vision between normal sight and “sense all” sight which gives an outline of invisible tokens.


Stats

#12
add current cpu, mem, io, net stats on containers, services, tasks, nodes
add -f for streaming on all current stats
(using single query Chris idea and coded group-by Tony idea)
Not implemented
-historic data using --since, --until, --period
tests ok:
amp stats --container
Display containers list with cpu, mem, io, net
amp stats --container -f
Display containers list with cpu, mem, io, net, streaming mode
amp stats --service -f
Display service list with cpu, mem, io, net, streaming mode
(then cpu%, mem% could be greater then 100% in multi nodes env)
amp stats --container --service-name=kafka -f
Display kafka containers list with cpu, mem, io, net, streaming mode
amp stats --task --service-name=kafka -f
Display kafka task list with cpu, mem, io, net
amp stats --task --cpu --mem
Display kafka task list with only cpu, mem
amp stats --node
Display nodes list with cpu, mem, io, net
all combinaison between work:
--cpu --mem --io --net
--container --task --service --node
filters:
--service-name --service-id
--task-name --taks-id
--container-id --container-name
--node-id
--datacenter --host

My review is In progress, but looks like YOU have accomplished great feats. There are a lot of conflicts with master, but first glance looks great.

I can't resolve conflits, i created a new branch 'stat2' from master and move update on it
Close this one

delete branch also


Use GitHubReleaseManager in Build Process

The required formatting within our Release Notes has changed slightly, so make sure to update GitHubReleaseNotes to match what is now required, and include this in the repository for use on Build Server

GitHubReleaseManger will now be used to do the following:

Generate Release Notes for Milestone when a merge into master branch happens
Export all Release Notes when a tag is created
Add the final assets to the release
Close the milestone associated with the release


Python-kivy: init at 1.10.0

Motivation for this change
Kivy is an Open source Python library for rapid development of applications
that make use of innovative user interfaces, such as multi-touch apps.
Most of Kivy's dependencies are optional, so defining a good "default" set of useful dependencies was a bit of a challenge. The present set of dependencies works well for me, but more dependencies, or even options for configuring the package, may be required in the future.
There is also some discussion at https://github.com/kivy/kivy/issues/5367
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] Linux

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

@FRidh I've responded in the above remarking that I'm not confident enough in my knowledge of Nix packaging to push forwards from here. Any chance you could implement your own remarks/requests so that we can push this PR forward and get it accepted?

I'm closing this pull request; it no longer works against the current version of master, and updating is non-trivial at the moment. I might reopen a similar request at a later point in time.


Chooser interface is not helping anyone

In testing real client sites, we are usually locking down chooser'y things to a single item, which doesn't make the choices panel clear as to its function. The crop controls being on this un-understood UI can be difficult.

I think you are saying the interface is unclear when it's a single-select
situation... is this ticket meant to capture anything that also applies to
other scenarios?
On Tue, Oct 31, 2017 at 9:35 AM, Stuart Romanek<EMAIL_ADDRESS>wrote:

In testing real client sites, we are usually locking down chooser'y things
to a single item, which doesn't make the choices panel clear as to its
function. The crop controls being on this un-understood UI can be difficult.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/punkave/apostrophe/issues/1080, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAB9fQkmj-oCv_rOS1pOvukosKb2Vm3Zks5sxyIQgaJpZM4QMv0b
.

--
*THOMAS BOUTELL, *SUPPORT LEAD
P'UNK AVENUE |<PHONE_NUMBER>  |  punkave.com


⚠ Jenkins Plugins Artifactory has degraded performance

In b5fa7cb, Jenkins Plugins Artifactory (https://get.jenkins.io/plugins/artifactory/) experienced degraded performance:

HTTP code: 200
Response time: 1179 ms

Resolved: Jenkins Plugins Artifactory performance has improved in 0118bc3 after 12 minutes.


Implement Bolt Routing protocol (closes #322).

Fixes #322.
This pull introduces/changes:

Support for bolt+routing. The bolt+routing protocol is necessary to connect to Neo4j Enterprise Causal Clusters. This PR adds support for its load-balancing and service discovery features, which are mostly... er... bolted onto the core Bolt protocol.

Caveats:

Tests needed. It's in desperate need of some unit tests, but we've been using it in production at https://ignota.com/ quite happily for a little over a week now.
Rubocop cleanup needed. Shouldn't be too taxing.
Design up for grabs! There are divergences with patterns used elsewhere in the gem, some intentional and some not-so-; this is my first time really digging deeply into its architecture, so I'm happy to entertain conversations about whether a better design could be arrived at.

Grateful as always for your thoughts and comments! Glad to be able to give something back to a project that's been invaluable to me these past few months. 💖
P.S.: Let me know if I can help set up a dev environment with Neo4j EE! Don't want you to have to go into it sight unseen.
Pings:
@cheerfulstoic
@subvertallchris

Coverage increased (+1.4%) to 86.069% when pulling 818f8db149167d3a13878fbe4b55d6cd350f7778 on ignota:bolt-routing into e4a263999017e1b58570f657351b741c6146d0c8 on neo4jrb:master.

Hey!  Sorry, I'm not currently maintaining the gem but it's awesome that somebody worked on this!
Some former colleagues of mine were potentially going to be working on this, so I would like to give them a heads up:
@leviwilson
@StephenTurley
@walterg2

Glad to see this being worked on too. Thank you! I recall the BOLT implementation having some performance issues compared to HTTP. Has that changed at all?

I believe when I was last testing them they were comparable, but then I also implemented some improvements to the performance.  I don't remember the results, but I think it was something like a 5-15% improvement from before.  Those changes are on master of neo4j-core.  The biggest change didn't actually have anything to do with the Bolt protocol but had to do with the fact that logging string was always being generated (regardless of if the log level was set to log or not).  So the improvement should mainly be on production where you don't generally log the queries.

@cheerfulstoic Thanks for pinging the right people! Sorry to hear you've stepped away from the gem, but good luck with whatever comes next.
@StephenTurley I've heard the same thing about performance issues, but unfortunately this changeset wouldn't touch them---it's still using the same Bolt protocol under the hood, it just adds the service discovery features from Bolt Routing onto the top.

@phyllisstein I just had literally a 5 minutes look through the PR so please excuse me if I missed some obvious details. Is the goal of the driver to provide load balancing for read-only databases?
One of the important features of bolt+routing is ensuring that one can read their own writes which is solved with bookmarks and which would need changes in the neo4j gem, its API and all the way to client code.

@phyllisstein have you continued to use this in production?
@klobuczek do you see any obvious issues? It seems that without the service discovery in this PR, we are left to find our own workarounds for dynamically discovering the elected leader in causual clusters, no? In other words, is this PR strictly an improvement despite not implementing bookmarks?

Hey! Forgive me for neglecting this PR (and @klobuczek's very thoughtful and generous feedback in #322). I have indeed been using this code in production since I first submitted it. That said, I use the word "production" extremely loosely in this context: the application I'm running sees very little traffic, so it's not impossible there are bugs lurking.
Reviewing the branch as it stands, I'd flag two areas of especial concern. The first is that the heuristics for creating and destroying sessions feel a little shady (there's this, e.g., and all'a this). If session handling is broken, your app might hang on to more open connections than it needs, hogging server memory and preventing Neo4j from gracefully accepting new connections. The second is that I plum quit before implementing causal chaining. This has already introduced one or two bugs into my own app, especially with background jobs. In cases (like file uploads) where the asynchronous code runs soon after graph CRUD code, it's not impossible (indeed, not uncommon) for the job's environment to connect to a read replica that hasn't received the replicated transaction yet.
The first issue, sadly, is a bit of a ¯\_(ツ)_/¯ at this point, but I'll try to find some time to put some thought into the second this weekend. If you wind up experimenting with this branch, I'd be curious to know how it goes! And if you have any questions about your specific use case, I'd be happy to talk through them over e-mail.

@phyllisstein would you be interested in contributing or at least reviewing https://github.com/neo4jrb/neo4j-ruby-driver? It is meant to be a fully compliant neo4j driver on which are going to base the neo4j/neo4j-core gem. So unfortunately this PR will not make it to master anymore, but your experience would be invaluable in building the new solution on top of the driver.

I've glanced at the driver code once or twice. It definitely looks impressive, and I'm glad to see that it's going to obviate this (imperfect, buggy) work. I've been looking at migrating my app to another stack, but kinda reluctantly. I'd love to learn more about where the Ruby driver code stands, what the delta is between its current state and getting it integrated with the OGM, and whether there's anything I can do to contribute.
Do you have a Slack set up or something? If not, my e-mail's in my profile, and I'd love to talk more.

Hi @phyllisstein we are all here: https://gitter.im/neo4jrb/neo4j#


Updated sending domains docs for new association with tracking domains.

This looks good to me. Thanks @gweber811


Feature Request: Extend Summarise using LLM task to print the results in the out dir

One of the use cases I have to is look at legacy COBOL code and generate summaries and use that output to create requirements documents for greenfield app rewrite.
I have been having a fair amount of success with RAG & LLMs but I really like the bottom up summarization approach rekt takes. I would like to see if we get better results with this tool.
It would be great if the task can:

Print/output all the individual summaries in a json(?) format.
Also, output the summary of the entire program in the text(?) format bringing all the AST and data structure summaries together.

Is this doable?

How about a JSON which reflects the syntactic structure of the code, but has an additional summary field for every node?
Are you looking for all the summaries appended together in a flattened form? Or, a single LLM summary of all of these summaries?

That works 👍
I can append it from the JSON above or by fishing it out of Neo4j. So really looking for the latter - Single LLM summary of the entire program.

The first piece of functionality should be working in commit a28e1ecf345cf9153a16afac9e93fcc2ce419868. The only commands you need to run are "BUILD_BASE_ANALYSIS WRITE_LLM_SUMMARY".
Note that this does not populate the graph DB with the summaries, but simply outputs it as a JSON file.
For now, populating the graph DB is a separate task.
Let me know if this fits your use case.

This works great, thanks!


debugger.css references invalid image files

the debugger.css file references images that don't exist. for example condBorders.png.
This can cause issues if you are using any postprocessing to manage static resources, as the invalid references can crash certain tools. For example - this one with django's ManifestStaticFilesStorage

That little thing is breaking our entire production build

But no changes in 5 years in this repo, I am confused, when did we deploy last

Yes, same here


Watch fail returns ABORTED status (like it used to.)

Where are all the tests this change must have broken?  :)

Yeah, AFAIK all of the Watch() stuff is untested, right @pphaneuf ?


Support SSL like Kemal.

Prerequisites

[x] Put an X between the brackets on this line if you have done all of the following:

Reproduced the problem
Checked that your issue isn't already filed: https://github.com/Amber-Crystal/amber/issues
Checked that there is not already a Crystal Shard that provides the described functionality: http://crystalshards.xyz/

Description
Currently Amber doesn't support SSL, see gitter comment
Steps to Reproduce

Install Amber:CMD
Create new Amber project
Try to configure SSL on Amber

Expected behavior: Amber supporting SSL
Actual behavior: Need to use external program like Nginx to use SSL
Reproduces how often: 100%
Versions
0.1.5
Additional Information
@sdogruyol, the creator of Kemal said:

it's simple enough
just pass SSL Context to HTTP::Server

Currently, Kemal does the following:
./your_kemal_app --ssl --ssl-key-file your_key_file --ssl-cert-file your_cert_file

See: http://kemalcr.com/docs/ssl/

Solved with https://github.com/amber-crystal/amber/pull/152


Added Icelandic translation

Hi @bjarkithordarson, thanks a lot for the PR!
I couldn't get the translations to work right away. I'll need to have a closer look at this and will get back to you :)

I'm afraid I still can't get this to work, app.getLocale() doesn't return is if my system language is set to Icelandic.
I'm still merging this, maybe the language isn't supported by Electron yet and that might change in the future.


[hierarchical widget] error when no results

Steps to reproduce:

empty query
refine on hierarchical widget
type a random character until there is an error

seems to be an issue of the helper

linked to https://github.com/algolia/instantsearch.js/pull/440?

not sure this one is in master already, no ?

not sure this one is in master already, no ?

Yes it was fixed so you have another issue maybe

@maxiloc Do you still have the issue? Can we close this one?

Yes if the helper have been updated we can close it

We didn't do a release of the helper. Will do that.

Humm didn't we

I think this one is fixed. Can you check @maxiloc ?


Publish on hub.docker.com

Any plans to publish this on docker hub directly?
Seems really cool, was looking excatly for that, will give it a try later on.
I'm asking for docker hub simply because for the system i would use it for (unraid), installing from docker hub is default.

Hey @martinjuhasz!
Thanks, happy to hear that and excited about possible feedback :)
Currently I already publish on hub.docker.com as well, you can access it here.


Auto-generated nodegroups have errors?

I started a new 'dev' RACK image just now; it appears to be pre-populated with 'auto generated ingestion' entries.  One of these (ingest_TEST_EXECUTION) is being used by the GE data set, but it returns errors regarding the http://arcos.acert/GrammaTech#memory property. Similarly, loading this nodegroup from the newly started RACK image produces a related error, as shown in the attached image.

This has been fixed. A little background: we changed setup-rack.sh so that it no longer loads all the overlays. That shell script is used to build the docker image. Consequently, we also changed the way we auto generate the set of ingestion nodegroups.


Is it normal during training for getting artifacts on the generation results?

Hi,
Thanks for your really great work.
I am trying to finetune the model and use the same mask generation strategy on the places dataset.
But I found the intermediate-generation results have severe artifacts problems.
I would like to ask do you think it is normal? Is it overfitting or underfitting? Thanks

hi. Im interested about finetune the model by using my owndataset as you did.
can you suggest me what should i do too because I am very new to this field.
thankyou @shileims


ARM64 build

Hi everyone,
Would it be possible to make this recipe build a package version for the ARM64 platform? Having tested it on an Apple M1 laptop, the build.sh should work as it is.
Thank you in advance.
ymm

Fixed by https://github.com/conda-forge/libusockets-feedstock/pull/6, thanks @ymontmarin for opening the PR that triggered the bot!


Select Option Contracts Based on Greeks

Option universe selection selects on price, strikes etc now but Valery requests Option Contracts selected on Greeks / Implied Volatility. Currently these are calculated in inline -- so we don't have them available at universe selection time.

I'd also like to see support for this. Any update?

I'd also like to see support for this. Any update?

+1 to this.
Any progress?

+1 to this.
Any progress?

+1 on this

+1 on this too

+1 on this also. How's the progress?

+1!

Any update on this? Running option strategies on many securities is quite slow as I want to trade a specific delta, or a specific premium, which OptionChainProvider doesn't easily allow for.
For instance, the strikes can expand greatly in high vol/high vix eras, for instance today the $0.50 SPX put expiring in two days was the 3,500 strike with SPX trading around 4155. The market was selling these deep puts for that much premium and there would be no way I'd guess I'd have to go that deep for a $0.50 put were I to use OptionChainProvider to optimize and speed things up.

Looking forward to seeing this :)

Plan is:

Standardize options and futures to use universe data files like the rest of LEAN(https://github.com/QuantConnect/Lean/issues/6861)
Create the options universe files with the greeks precalculated and passed in as part of their filtering options.
Calculation of daily options universe as a LEAN Data stack job.

It's a heavy project and will require gutting thousands of lines of code but will dramatically standardize the internals of LEAN universes which is very exciting.

Side effects of the plan:

Filtering will be every day instead of every minute, but it's too much churn and noise for most people so we don't think people will care really. Anyone impacted can just set a wider strike range.
Much faster options backtesting.

With daily refresh will it be possible to say "at 11AM, buy the option contract that currently has delta = 0.2"?
I think it's a common scenario to find an option by delta at current moment. Delta can change dramatically intraday, especially if the option is approaching expiration, so the delta value from the beginning of the day might not be very useful in such cases

Equity and index options can be selected based on greeks, creating new issue to track this functionality for FOPs https://github.com/QuantConnect/Lean/issues/8438


Disable persisted cache for API responses, add refresh button

This should disable any persisted cache for all API responses in the app.
It also adds a "Last updated" info on every page, in the header. The messages page will not show this, as the data refresh is handled by the table in the body.

@MikeEdgar this should be good to go now

@riccardo-forina there are two playwright tests failing (both browsers) that look like they might be legitimate errors

  4 failed
    [chromium] › MessagesPage.test.tsx:3:5 › Messages page ─────────────────────────────────────────
    [chromium] › PartitionsPage.test.tsx:3:5 › Partitions page ─────────────────────────────────────
    [firefox] › MessagesPage.test.tsx:3:5 › Messages page ──────────────────────────────────────────
    [firefox] › PartitionsPage.test.tsx:3:5 › Partitions page ──────────────────────────────────────

Well the test suite's been completely updated to reuse the navigation bits and the auth bits as well. It should be easier to grok and maintain, and should pass the checks

yep!


Merge filter definition with remote filter, when calling

This will allow properties set inside of the config.json to be read and understood by the downloaded filter, when running.
Code for this currently exists for the settings key, but we should expand this solution for all keys inside of filters.

Example:
{
    "filter": "bob",
    "venvSlot": 4
}

We need to make sure that venvSlot gets propagated to the remote filter, when it runs.


fix - local variable 'documents' referenced before assignment

Description

fix  UnboundLocalError in superagi.worker # summarize_resource
Type of change

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Docs update

Checklist

[x] My pull request is atomic and focuses on a single change.
[ ] I have read the contributing guide and my code conforms to the guidelines.
[ ] I have documented my changes clearly and comprehensively.
[ ] I have added the required tests.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: TransformerOptimus:x: Fluder-ParadyneYou have signed the CLA already but the status is still pending? Let us recheck it.

already fixed by directly pushing to main


RTSP source not working

Which version are you using?
v1.1.0
Which operating system are you using?

[ ] Linux amd64 standard
[ ] Linux amd64 Docker
[ ] Linux arm64 standard
[ ] Linux arm64 Docker
[ ] Linux arm7 standard
[ ] Linux arm7 Docker
[ ] Linux arm6 standard
[ ] Linux arm6 Docker
[X] Windows amd64 standard
[ ] Windows amd64 Docker (WSL backend)
[ ] macOS amd64 standard
[ ] macOS amd64 Docker
[ ] Other (please describe)

Describe the issue
RTSP source was working upto version 1.0.0, but gives following error after upgrading to 1.1.0:
2023/10/07 17:41:17 ERR [path test] [RTSP source] invalid SDP: session name not present
Describe how to replicate the issue
simply start the server with RTSP camera source, and it gives directly error

start the server
publish with RTSP Source
read with RTSP

Did you attach the server logs?
mediamtx_v1.1.0.log
mediamtx_v1.0.0.log
yes
The same rtsp url is working in version 1.0.0 . Logs attached.
But not working in version 1.1.0. Logs attached.
Did you attach a network dump?

no

Hi, the same problem on Linux with docker mediamtx 1.1.1

Thanks for providing all required material (server logs) that allowed to fix the issue. This is fixed by https://github.com/bluenviron/gortsplib/pull/439

added in v1.2.0


Add support for all official languages in Spain

Based on experience, I know that support for all official languages is important for any deployment in Spain.
While the current project already has an extensive list of voices for Spanish, documenting voices for all the remaining official languages in Spain would cement its viability.
The following additions should be considered:

Basque (eu)
Catalan (ca)
Galician (gl)
Valencian (doesn't really have an official BCP 47 language tag)

There are very few voices currently available for these languages, which should make it a fairly easy task.

A few notes about Valencian:

the only voice that I could find is under the list of Catalan voices on Apple devices
the following language tag is returned when calling getVoices() from Chrome for this voice: ca-ES-u-sd-esvc

For now, I didn't create a separate language file for Valencian, but this voice has been properly labeled as Valencian.

For now, I've adopted a limited localization strategy for these voices, limiting things to localizing Spanish voices to Basque, Catalan and Galician. I'll need a similar strategy when adding languages moving forward, otherwise things could get a little out of control (thanks Apple).


fix link to subnet tagging in development guide

Issue, if available:
in this guide https://karpenter.sh/docs/development-guide/ and the link embedded here (below) does not work:

If you created your cluster on version 1.19 or above, you may need to tag your subnets as mentioned here.

Description of changes:
I changed the link to use a hugo reference, instead of linking to the old github content.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

sorry for the PR that should have been a draft 😅
it's better now


misc.app_dev.libcxx test fails to build for qemu_x86_64

Describe the bug
misc.app_dev.libcxx test fails to build for qemu_x86_64 due to -lstdc++ not being specified while linking.
Since misc.app_dev.libcxx is run as part of sanitycheck for x86 arch, sanitycheck also fails. This seems to have gone unnoticed because CI does not currently build and run this test on qemu_x86_64.
Unrelated note: x86_64 is classified as x86 for some reason for both Kconfig ARCH and testcase arch; this should be addressed and fixed separately (maybe x86 should also follow how riscv arch handles riscv32 and riscv64).
To Reproduce
Steps to reproduce the behavior:

cd tests/application_development/libcxx
mkdir build && cd build
cmake -DBOARD=qemu_x86_64 ..
make

Screenshots or console output
Build fails with the following error:
FAILED: zephyr/zephyr.elf zephyr/zephyr.bin zephyr/zephyr.lst zephyr/zephyr.stat
: && ccache /opt/zephyr-sdk/x86_64-zephyr-elf/bin/x86_64-zephyr-elf-g++  -m64   zephyr/CMakeFiles/zephyr_prebuilt.dir/misc/empty_file.c.obj  -o zephyr/zephyr.elf  -Wl,-T zephyr/linker.cmd -Wl,-Map=/home/stephanos/Dev/zephyr-public/zephyr/tests/application_development/libcxx/build_2/zephyr/zephyr_prebuilt.map -Wl,--whole-archive app/libapp.a zephyr/libzephyr.a zephyr/arch/arch/x86/core/libarch__x86__core.a zephyr/lib/libc/newlib/liblib__libc__newlib.a zephyr/lib/posix/liblib__posix.a zephyr/soc/x86/ia32/libsoc__x86__ia32.a zephyr/subsys/random/libsubsys__random.a zephyr/subsys/testsuite/ztest/libsubsys__testsuite__ztest.a zephyr/drivers/serial/libdrivers__serial.a -Wl,--no-whole-archive zephyr/kernel/libkernel.a zephyr/CMakeFiles/offsets.dir/arch/x86/core/offsets/offsets.c.obj -L/opt/zephyr-sdk/x86_64-zephyr-elf/x86_64-zephyr-elf/lib64 -L"/opt/zephyr-sdk/x86_64-zephyr-elf/bin/../lib/gcc/x86_64-zephyr-elf/8.3.0/64" -L/home/stephanos/Dev/zephyr-public/zephyr/tests/application_development/libcxx/build_2/zephyr -lgcc -Wl,--print-memory-usage -m64 -Wl,--gc-sections -Wl,--build-id=none -Wl,--sort-common=descending -Wl,--sort-section=alignment -u_OffsetAbsSyms -u_ConfigAbsSyms -nostdlib -static -no-pie -Wl,-X -Wl,-N -Wl,--orphan-handling=warn -lm -lc -lgcc -L"/opt/zephyr-sdk/x86_64-zephyr-elf/x86_64-zephyr-elf"/lib/64 && cd /home/stephanos/Dev/zephyr-public/zephyr/tests/application_development/libcxx/build_2/zephyr && cmake -E rename zephyr_prebuilt.map zephyr.map && /opt/zephyr-sdk/x86_64-zephyr-elf/bin/x86_64-zephyr-elf-objcopy -S --gap-fill 0xff --output-target=binary --remove-section=.comment --remove-section=COMMON --remove-section=.eh_frame zephyr.elf zephyr.bin && /opt/zephyr-sdk/x86_64-zephyr-elf/bin/x86_64-zephyr-elf-objdump -S zephyr.elf > zephyr.lst && /opt/zephyr-sdk/x86_64-zephyr-elf/bin/x86_64-zephyr-elf-readelf -e zephyr.elf > zephyr.stat
Memory region         Used Size  Region Size  %age Used
             RAM:       87088 B         4 MB      2.08%
        IDT_LIST:          0 GB         2 KB      0.00/opt/zephyr-sdk/x86_64-zephyr-elf/bin/../lib/gcc/x86_64-zephyr-elf/8.3.0/../../../../x86_64-zephyr-elf/bin/ld: app/libapp.a(main.cpp.obj): in function `__gnu_cxx::new_allocator<int>::deallocate(int*, unsigned long)':
/opt/zephyr-sdk/x86_64-zephyr-elf/x86_64-zephyr-elf/include/c++/8.3.0/ext/new_allocator.h:125: undefined reference to `operator delete(void*)'
/opt/zephyr-sdk/x86_64-zephyr-elf/bin/../lib/gcc/x86_64-zephyr-elf/8.3.0/../../../../x86_64-zephyr-elf/bin/ld: app/libapp.a(main.cpp.obj): in function `std::_MakeUniq<make_unique_data>::__single_object std::make_unique<make_unique_data>()':
/opt/zephyr-sdk/x86_64-zephyr-elf/x86_64-zephyr-elf/include/c++/8.3.0/bits/unique_ptr.h:831: undefined reference to `operator new(unsigned long)'
/opt/zephyr-sdk/x86_64-zephyr-elf/bin/../lib/gcc/x86_64-zephyr-elf/8.3.0/../../../../x86_64-zephyr-elf/bin/ld: app/libapp.a(main.cpp.obj): in function `std::default_delete<make_unique_data>::operator()(make_unique_data*) const':
/opt/zephyr-sdk/x86_64-zephyr-elf/x86_64-zephyr-elf/include/c++/8.3.0/bits/unique_ptr.h:81: undefined reference to `operator delete(void*, unsigned long)'
/opt/zephyr-sdk/x86_64-zephyr-elf/bin/../lib/gcc/x86_64-zephyr-elf/8.3.0/../../../../x86_64-zephyr-elf/bin/ld: app/libapp.a(main.cpp.obj): in function `__gnu_cxx::new_allocator<int>::deallocate(int*, unsigned long)':
/opt/zephyr-sdk/x86_64-zephyr-elf/x86_64-zephyr-elf/include/c++/8.3.0/ext/new_allocator.h:125: undefined reference to `operator delete(void*)'
/opt/zephyr-sdk/x86_64-zephyr-elf/bin/../lib/gcc/x86_64-zephyr-elf/8.3.0/../../../../x86_64-zephyr-elf/bin/ld: app/libapp.a(main.cpp.obj): in function `__gnu_cxx::new_allocator<int>::allocate(unsigned long, void const*)':
/opt/zephyr-sdk/x86_64-zephyr-elf/x86_64-zephyr-elf/include/c++/8.3.0/ext/new_allocator.h:111: undefined reference to `operator new(unsigned long)'
collect2: error: ld returned 1 exit status
%
ninja: build stopped: subcommand failed.

In terms of sanitycheck -v -N -l -p qemu_x86_64, refer to the following link for full log:
https://gist.github.com/stephanosio/d8ac379bced247b7f353a00382e9ebb1
Environment (please complete the following information):

OS: Ubuntu 18.04
Toolchain: Zephyr SDK 0.10.3
Commit: 7e722564df1586b722314146c8a427e48249f536

Additional context
This seems to have been broken for a while, at least for more than a week.
It seems to be more of a CMake problem actually:
https://github.com/zephyrproject-rtos/zephyr/blob/7e722564df1586b722314146c8a427e48249f536/cmake/extensions.cmake#L1350
Changing this to zephyr_check_compiler_flag(C ${option} ${check}) does add -lstdc++ back and the test successfully builds.

cc @andrewboie @SebastianBoe

due to -lstdc++ not being specified while linking

I see -lstdc++ has been added through "zephyr_ld_options" and not "zephyr_link_libraries". ld_options will test whether the flag is compatible with the toolchain and silently omit it if not, whereas link_libraries just applies it.
If the flag was not optional then it should have been using the zephyr_link_libraries API.
This still begs the question of why the flag failed the compatiblity check. But we could leave this as an open question and just change from zephyr_ld_options to zephyr_link_libraries.

If the flag was not optional then it should have been using the zephyr_link_libraries API.

I created a PR addressing this: #20415.

This still begs the question of why the flag failed the compatiblity check. But we could leave this as an open question and just change from zephyr_ld_options to zephyr_link_libraries.

I have seen linker_ld_options incorrectly filter out a valid linker option on multiple occasions. I think this deserves to be further investigated.


Add Python API support for multiple GPUs

I often need to use TotalSegmentator to perform preliminary segmentation on large datasets to create rough labels, which is a preprocessing method I frequently use in my current research. However, processing hundreds of patients one by one using TotalSegmentator on a single GPU is very slow and often takes several days. My school provides multi-GPU servers, so I’m wondering if the Python API can support multi-GPU acceleration?

The best way to utilise multiple GPUs for TotalSegmentator is to run it for several subjects in parallel on different GPUs. For TotalSegmentator itself it does not make sense to support MultiGPU since it anyways uses the GPU only for a few seconds.


Patch-4

chore: Rebranding to "Vertex AI Feature Store (Legacy)" + editorial fixes + changed "ingest" to "import".

@sen-sam You have some conflicts to resolve, before we can review the PR


[zh-cn]sync multi-tenancy.md

content/zh-cn/docs/concepts/security/multi-tenancy.md

/lgtm
/approve


Add prow tests

This change is

/test kubeflow-fairing-presubmit

Fixes #1

/retest

/retest

/assign @karthikv2k

@r2d4 is there a doc on how this setup works? if not can you write a one page summary about how it works?

For reference: Here's how the integration tests are set up in this PR
The kubernetes/kubernetes prow installation is set up to trigger a single presubmit test on this repository for pull requests.
That prow job is configured to use the base image that kubeflow uses across its tests and the "run_e2e.py" script that prepares the argo workflow that is contained in this PR.
The argo workflow is currently split into two steps - unit and integration tests. The unit tests run directly on the kubeflow testing infrastructure GKE cluster, while the integration tests trigger the same cloud build job we were previously running.
The cloud build job runs on a new kubeflow v0.5 cluster that runs in the kubeflow-ci project.

closing and cloning from this branch to take over the setup. Will create a new PR.


Update assertj-core to 3.20.0

Updates org.assertj:assertj-core from 3.18.1 to 3.20.0.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.assertj", artifactId = "assertj-core" } ]

labels: test-library-update, semver-minor

Superseded by #235.


Add hoogle support

The next version of stack will support a hoogle command, currently available on master.
bash-3.2$ stack hoogle 'a -> Maybe a'
Just :: a -> Maybe a
fromJust :: Maybe a -> a
isJust :: Maybe a -> Bool

This presents a good deal of features "for free":

Support C-h f-style documentation lookup for the ident at point.
Support a search-as-you-type buffer (or helm-like-driven).
An additional completion source.
Capability to automatically import the module necessary for a given identifier when GHC reports "not in scope".

And possibly other things I haven't thought of.
I will implement it in the same way as stack ghci --with-ghc intero: open a process buffer, run hoogle server inside it with a randomly generated available port, and then talk to it via the port and the JSON API. Example locally:
$ stack hoogle -- server  --port 3000 --local
$ curl 'http://localhost:3000/?hoogle=a%20-%3E%20Maybe%20a&mode=json'

The HTML in the results can be stripped out with a trivial regex (although another option may be to propertize the text too):
[{"url":"file:///Users/chris/.stack/programs/x86_64-osx/ghc-7.10.3/share/doc/ghc/html/libraries/base-
<IP_ADDRESS>/Prelude.html#v:Just","module":{"url":"file:///Users/chris/.stack/programs/x86_64-osx/ghc-
7.10.3/share/doc/ghc/html/libraries/base-<IP_ADDRESS>/Prelude.html","name":"Prelude"},"package":
{"url":"file:///Users/chris/.stack/programs/x86_64-osx/ghc-7.10.3/share/doc/ghc/html/libraries/base-
<IP_ADDRESS>/","name":"base"},"item":"<0>Just</0> :: a -> Maybe
a","type":"","docs":""}

Can we try this already with the git versions of stack and intero? What remains to be done?

@meditans what remains is setting up launching and installing/setting up of hoogle automatically from inside intero, without necessarily bothering people who don't want it. It takes some time to make it friendly and robust, but I haven't had much time to dedicate to it recently.
stack hoogle works with the latest stack release. intero needs a few internal functions implemented.

It would be great to just point at a function and have it's documentation open locally.

I'm not sure this is going to happen.


Fix for: Item selections needs two clicks on iOS (Issue #363)

Hi @shentao,
Could you please review and merge if everything is fine? This is for https://github.com/monterail/vue-multiselect/issues/363
It is closed but I'm still having that issue. This fix works just fine for me

Hey! Thanks for the contribution! :)
Could you please move the inline function to methods?
I could merge it afterwards.


Add option to add additional home root directories.

I have modified my Steam .desktop file to use a custom home directory to keep steam files and saves separated from the regular home directory. Would be nice if ludusavi could detect saves in additional home directories other than the  default one. For example it could be as an additional radio button besides Steam and Other.

Hi! Although Ludusavi currently only auto-detects the standard locations, you can add as many custom ones as you need. You can add a new root for the custom home folder (or modify the auto-detected one if you don't need it), keep the radiobutton as Steam (because the contents of the folder would be organized per normal Steam rules, even if the folder location is custom), and it should pick up your saves when you scan again.
As far as the auto-detection goes, #58 would add some related improvements, but I'm not sure about the implications of detecting .desktop files. It would probably depend on the .desktop file having a standard name and location in order to avoid false positives.

Ludusavi does not detect additional home directories even if I add it as another Steam root.
I have HOME=/ssd/steamhome in my Steam.desktop file, and add /ssd/steamhome as well as the normal Steam directory: /ssd/steamhome/.local/share/Steam. If I move a save from my real home folder to the /ssd/steamhome, the number of games ludusavi detects goes down.
Also I do not imply auto-detection in .desktop files should be added, because it's probably a very uncommon use case. I only want to manually add an additional home directory.

Oh, I get what you mean now. I was only considering the impact on where .local/share/Steam ends up, but not that the individual games would also respect the custom home and add their own files there. I'll look into adding support for this.

Awesome! And yes the games do respect the custom folder when they are launched through Steam.


Unable to get the (promise) demo to run; Blob object is required

I am not able to get the demo from the README.md to run; is there anything I am doing wrong?
My Code:
import { RecordRTCPromisesHandler, invokeSaveAsDialog } from 'recordrtc';

let stream = await navigator.mediaDevices.getUserMedia({
  video: true,
  audio: true,
});
let recorder = new RecordRTCPromisesHandler(stream, {
  type: 'video',
});
recorder.startRecording();

const sleep = (m) => new Promise((r) => setTimeout(r, m));
await sleep(3000);

recorder.stopRecording();
let blob = await recorder.getBlob();
invokeSaveAsDialog(blob);

The last line is actually causing the error: Uncaught (in promise) Blob object is required.

Nevermind, it is working now; I think there was some bad interplay with my virtual camera coming from OBS


Add method change_attractor

Tries to solve #676. Just changed syntax from  so it can act as an Orbit method. I also included a test based on iss from the examples module.

Thanks for the PR @jorgepiloto! I see one danger with this:
The original intent of the function was to change the attractor for the Galilean moons from the Sun to Jupiter. This makes sense, because the real attractor of these moons is Jupiter. In fact, if one takes the data of .from_horizons and just .propagate, the results are completely wrong, because the propagation happens as if Jupiter does not even exist.
I think having the possibility to change the attractor of any orbit in this way is quite dangerous. I should have thought about the problem when writing the issue.
What do you think about making this method a private function in poliastro.twobody.orbit and looking for a way to fix the mismatch of from_horizons?

Sure! Therefore, should we add something like:

Sure! What do you think about something like this?
ss = Orbit.from_horizons(name, attractor=Sun, **kwargs)

Looking at https://astroquery.readthedocs.io/en/latest/api/astroquery.jplhorizons.HorizonsClass.html, I don't think from_horizons can know which attractor should it use automatically. So yes, there should be a way for the user to specify that.
After thinking about your proposal a bit more (see thoughts in #676), I think Orbit.from_horizons(name).change_attractor(Jupiter) is a good idea. However, perhaps we could check wether the object falls inside the Sphere of Influence of the new attractor (not sure whether Laplace or Hill) and, if not, display a warning or even raise an error. What do you think @jorgepiloto?

It would be very easy to check by using the laplace_radius in poliastro.threebody.soi if the assumption of patched conics is suitable.
The problem comes when the orbit is under this sphere of influence but its nature is parabolic or hyperbolic (flyby case). The algorithm will change the attractor, but if the user tries to propagate, there would be some point at which computations are no longer correct and attractor should be changed again, as you said in  your comment.
Knowing the point at which the previous situation occurs is easy but implement that inside the propagators methods I think may be crazy...
We could enable this method to work if two conditions are fulfilled:

We are under the sphere of influence
Orbit of the body is elliptical or circular (closed orbit)

Otherwise, we raise an error for the moment. Could this be a good approach?

Knowing the point at which the previous situation occurs is easy but implement that inside the propagators methods I think may be crazy...

Actually, now that SciPy propagators have support for events, it's not that difficult :wink: but let's leave that for a future issue.
I agree with raising an error if the orbit is outside the sphere of influence of the target attractor with respect to the Sun. However, let's not consider the eccentricity here, to allow open orbits as well.

Wow, investigating these failures.

Oops, we introduced a circular import:
  File "/home/circleci/repo/venv/lib/python3.7/site-packages/poliastro/twobody/__init__.py", line 1, in <module>
    from .orbit import Orbit
  File "/home/circleci/repo/venv/lib/python3.7/site-packages/poliastro/twobody/orbit.py", line 22, in <module>
    from poliastro.threebody.soi import laplace_radius
  File "/home/circleci/repo/venv/lib/python3.7/site-packages/poliastro/threebody/soi.py", line 32, in <module>
    from poliastro.twobody import Orbit

The Orbit object is used in the SOI module to... Compute the classical elements of the planets!
https://github.com/jorgepiloto/poliastro/blob/dbbf332386e135eb64d0bf62d114350deb5c072d/src/poliastro/threebody/soi.py#L54-L55
This leads me to two things:

My dreaded from_body_ephem strikes back https://github.com/poliastro/poliastro/issues/445 (see some comments at the end about sbpy)
We had a long discussion with @AunSiro about adding some "mean" elements to the Body classes that we could use for this kind of thing https://github.com/poliastro/poliastro/pull/153

So my solution to this circular import is to make the Orbit import in poliastro.threebody.soi "delayed" while we figure out a better way.

I made several changes to your code:

Made it more general: instead of checking for the Sun, I'm checking for attractor.parent (in case people want to define their own planetary systems)
Removed the capability to change the plane to simplify the code (probably we should have another method for that)
Implement a short-circuit in case the target and current attractor are the same
Allow only changes from attractor to parent and vice-versa

Aaaaaand merging! Thanks @jorgepiloto to get the ball rolling!


Support redirect for Logout flows

• Builds on #16 Inflating redirect response
• Reverts [638ce6e4 accepting redirect as well as post; redirect not verified(638ce6e4e257d99bf1f5b59c2b76f0890744ded9)
• Implements
Support HTTP-Redirect binding for IdP to SP SLO

I would love to see this merged - did you try it with SLO of OneLogin

I had a bug when retrieving the Issuer from the LogoutRequest. I've tested with SimpleSamlPhp and Onelogin. Although I can't find how to setup OneLogin to include a signature for the LogoutRequest to make sure the signature validation works as well.

To add review, you could link to the part of the SAML spec that discuss SP SLO and related topics.
I think this will be a nice feature to add, but want to be sure about our spec compliance.
Thanks.

Also could you say more about why the mentioned commit was reverted?

@stavros-wb Thanks! I'll look for the revised PR.

@stavros-wb I'm thinking of doing a "1.0" release within the next 10 days and could include this revised PR if it's ready.

thanks @markstos , rebased and squashed on latest master

@stavros-wb This looks good to me. Are they are related updates to the README that need to be made for this?
@cjbarth Any other concerns here before this gets merged?

@stavros-wb Also, can you confirm if this is considered a breaking change?

I don't have any concerns about this, but I also don't have a lot of experience with this. I do feel that a README update is warranted though.

@markstos

@stavros-wb Also, can you confirm if this is considered a breaking change?

Nope. this is not a breaking change. It supports redirects on Logouts, while right now passport-saml supports only POST
@cjbarth

I don't have any concerns about this, but I also don't have a lot of experience with this. I do feel that a README update is warranted though.

I don't think a README entry is required. I'm not opposed to it, though. SLO is already supported if the protocol binding is POST by providing the callback url to the IDP. changing it to redirect would only require changing the setting on the IDP, no further configuration on SP.
What do you have in mind for the docs?

I think it would be useful to mention in the Logout section of the docs that we support SLO and explicitly mention that we support both POST and Redirect bindings.

@markstos I've added a small list regarding SLO in the README file


Cord field 220 people user list

Closes #220

Rename PersonCard to UserListItemCard to match other similar card components
Update UserListItemCard  to accept user prop of type User instead of multiple individual user-attribute props, to match other similar card components
Update styling of UserListItemCard to match Figma design and add loading state and stories file
Create UserListItem fragment for UserListItemCard
Create Users scene and add to Root routes
Create UserList, UserSortOptions, and stories file for UserSortOptions
Create query for UserList, using UserListItem fragment

We were repeating the same <div className={classes.root}> in all our top-level routes (Projects, Languages, People, Partners), with the exact same properties, so we also create a ListContainer component and replace the wrapper <div> with it in the above-mentioned <Scene>List components.

@richardgirges @CarsonF This will be ready to go when I can replace some hard-coded fields with queryable data that current throws errors when I run the query. Those fields are avatarLetters and organizations -> name. The design shows a role attribute for the user for the organization ("Field Coordinator" is what the designs show for all the users), but this attribute doesn't appear to exist in the API. Should this be removed?


Intermittent Unknown error 258 with no obvious cause

Describe the bug
On occasions we will see the following error
Microsoft.Data.SqlClient.SqlException (0x80131904): Execution Timeout Expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.
 ---> System.ComponentModel.Win32Exception (258): Unknown error 258
   at Microsoft.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
   at Microsoft.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
   at Microsoft.Data.SqlClient.SqlCommand.InternalEndExecuteReader(IAsyncResult asyncResult, Boolean isInternal, String endMethod)
   at Microsoft.Data.SqlClient.SqlCommand.EndExecuteReaderInternal(IAsyncResult asyncResult)
   at Microsoft.Data.SqlClient.SqlCommand.EndExecuteReaderAsync(IAsyncResult asyncResult)
   at System.Threading.Tasks.TaskFactory`1.FromAsyncCoreLogic(IAsyncResult iar, Func`2 endFunction, Action`1 endAction, Task`1 promise, Boolean requiresSynchronization)

However, SQL Server shows no long running queries and is not using a lot of it's resources during the periods where this happens.
It looks to be more of an intermittent connection issue but we're unable to find any sort of root cause.
To reproduce
We're not sure of the reproduction steps. I've been unable to reproduce this myself by simulating load. From what we can tell this is more likely to happen when the pod is busy (not through just HTTP, but handling events from an external source) but equally it can happen randomly when nothing is really happening on the pod which has caused us quite a substantial amount of confusion.
Expected behavior
Either more information on what the cause might be, or some solution to the issue. I realise the driver might not actually know the issue and it may really be a timeout to it's point of view. We're not entirely sure where the problem lies yet, which is the biggest issue.
Further technical details
Microsoft.Data.SqlClient version: 3.0.1
.NET target: Core 3.1
SQL Server version: Microsoft SQL Azure (RTM) - 12.0.2000.8
Operating system: Docker Container - mcr.microsoft.com/dotnet/aspnet:3.1
Additional context

Running in AKS, against Elastic Pools.
SQL Server shows no long running queries
We sometimes get a TimeoutEvent from the metrics that are collected from the pool. On occasions when we do get them, the error_state will be different.

For example, we had one this morning that was 145. We don't know what this means can find no information on what these relate to. I've raised a ticket with the Azure Docs team to look at this. I'll add more onto this when they happen as we've not been keeping track of the error_state codes as we're not sure if they're even relevant.

This might be related to this ticket - https://github.com/dotnet/SqlClient/issues/647

However we don't see the ReadSniSyncOverAsync

We do have event counter metrics being exported to Prometheus but have found no obvious indicators that something is wrong

As we have seen before in issue #647 the underlying reason may come from a different problems which may not be entirely drivers fault.  any interruption in connectivity a missed port or socket failure could lead to this issue. We cannot say more without having more on the context of application. The most helpful step could be a minimal repro which it is usually impossible to create. However we can capture EventSource traces and see what has gone wrong. I would suggest closing the issue and follow #647.

@JRahnama happy to close the issue and add my information to that ticket, but I want to be absolutely sure that the ticket referenced (which I've also included in the original report) is not just for the ReadSniSyncOverAsync errors which are not in our stacktrace.
In the mean time, we'll hook up the EventSource you linked to gather some more information. Did not realise that was available!

@dantheman999301 if you use perfview it will capture all events. make sure you filter them by Microsoft.Data.SqlClient.EventSource name.

@JRahnama unfortunately due to the nature of this issue (only showing up in our production environment, which is in Linux Docker in AKS), I think perfview is not going to work for us, as nice as it would be.
We've managed to wrangle the EventListener so that it will only log on errors. These errors usually show up at least once in the morning for us in a certain service during weekdays so fingers crossed on Monday I should have something for you.

@JRahnama good news is, we managed to get the logs (we think).
Bad news is, there are 200,000 of them. Unfortunately it didn't filter like I thought it would and as it was happening during a busy period and we have all Keywords on, there was a lot to collect.
We need to work out how we're going to export them from Kibana, and obviously it's not as good as a full dump. Perfcollect might work but we'll need to work out how we're going to hook it up and run it over what is usually a period of an hour without having an impact on our production systems. We might also be able to use dotnet-monitor but it would require some investigation too.
Let me know if it's of any use.

We got same issue 5 days ago even our code was working and didn't change few days ago

@dantheman999301 sorry for the late response we got busy with preview release. Any kind of log that shows or help us to understand where it happens would be helpful.

We got same issue 5 days ago even our code was working and didn't change few days ago

Same questions applies to your case as well. Any repro or tracing logs would be helpful. I would also suggest investigation network traces as well. that could clarify some of the underlying issues.

258 timeout is a common exception when the DTU limit is reached on Azure SQL. If on Azure, you can try to monitor the Max DTU percentage and see if it hits the limit.

@oyvost In the issue we are facing we can see that the connection is not even made to SQL Server so it's not a throttling issue or similar.
For example, we had an error about 20 minutes ago and it was utilising 4% of the available DTUs.
@JRahnama just to get back to you, the logs we thought we had turned out not to be any good, there was a lot of duplication due to the way we wrote the Event Listener. The closest we've got to any answers on this is that we think it's timing out trying to get a connection from the connection pool even though from what we could tell from the event counters there seemed to be plenty of available connections in the pool. We're not overly confident this is the cause but it's something to go off.

Hello,
We currently face a similar issue since approximately 1 month, with SQL queries facing Win32Exceptions with code 258 and no obvious cause. The DB itself signals no issue with very low DTU usage.

@DLS201 can you post the stack trace of the exception? have you checked the tcp and socket events/logs?

Hi,
Here is our error message:
Microsoft.Data.SqlClient.SqlException (0x80131904): Execution Timeout Expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.\n ---> System.ComponentModel.Win32Exception (258): No error information\n   at Microsoft.Data.SqlClient.SqlCommand.<>c.<ExecuteDbDataReaderAsync>b__207_0(Task1 result)\n   at System.Threading.Tasks.ContinuationResultTaskFromResultTask2.InnerInvoke()\n   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)\n--- End of stack trace from previous location ---\n   at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot, Thread threadPoolThread)\n--- End of stack trace from previous location ---\n   at Microsoft.EntityFrameworkCore.Storage.RelationalCommand.ExecuteReaderAsync(RelationalCommandParameterObject parameterObject, CancellationToken cancellationToken)\n   at Microsoft.EntityFrameworkCore.Storage.RelationalCommand.ExecuteReaderAsync(RelationalCommandParameterObject parameterObject, CancellationToken cancellationToken)\n   at Microsoft.EntityFrameworkCore.Query.Internal.SingleQueryingEnumerable1.AsyncEnumerator.InitializeReaderAsync(AsyncEnumerator enumerator, CancellationToken cancellationToken)\n   at Microsoft.EntityFrameworkCore.Storage.ExecutionStrategy.<>c__DisplayClass33_02.<<ExecuteAsync>b__0>d.MoveNext()\n--- End of stack trace from previous location ---\n   at Microsoft.EntityFrameworkCore.Storage.ExecutionStrategy.ExecuteImplementationAsync[TState,TResult](Func4 operation, Func4 verifySucceeded, TState state, CancellationToken cancellationToken)\n   at Microsoft.EntityFrameworkCore.Storage.ExecutionStrategy.ExecuteImplementationAsync[TState,TResult](Func4 operation, Func4 verifySucceeded, TState state, CancellationToken cancellationToken)\n   at Microsoft.EntityFrameworkCore.Storage.ExecutionStrategy.ExecuteAsync[TState,TResult](TState state, Func4 operation, Func4 verifySucceeded, CancellationToken cancellationToken)\n   at Microsoft.EntityFrameworkCore.Query.Internal.SingleQueryingEnumerable1.AsyncEnumerator.MoveNextAsync()`
Database in an Azure SQL instance, no error on this side.

@DLS201 Hello! Any progress on this? I'm encountering the same issue, but on three different occassions. I've documented them as a question on Stackoverflow.

@mekk1t out of interest, what infrastructure have you got?
We've only ever been able to narrow it down (we think) to a timeout waiting for a connection from the connection pool. That said upping the connection pool amount and timeout seems to make no difference.

Hello,
Azure Support just told us that the product group identified the issue and will fix it Q4 2022.
Regards,

Azure Support just told us that the product group identified the issue and will fix it Q4 2022.

@DLS201 any chance you have more information on this? Maybe a link to a bug or something? We are investigating this issue currently and would like to know what MSFT knows...

I am having the exact same issue with this setup:
Microsoft.Data.SqlClient version: 4.1.0
.NET target: .NET 6.0
SQL Server version: Microsoft SQL Server Standard (64-bit) 15.0.2070.41
Operating system: Docker Container running on linux - mcr.microsoft.com/dotnet/aspnet:6.0

@DLS201 do you have a scope?  Does it happen for any .net client code running anywhere in Azure?
In my case I'm having tons of problems getting a .Net solution running in Spark for Synapse.
I'm opening a support case as well.  But you could save us all many, many days of time with CSS if you would point us in the right direction.  Generally CSS seems to not be highly technical, and they seem just as far removed from the Azure product groups as I am!
Interestingly I can run my spark cluster locally, outside of azure and I have no issues connecting to the same SQL database over expressroute.  It is only when my .net code also runs in azure that I have trouble connecting to Azure SQL.  This seems counter-intuitive.   (Another odd datapoint - the exact same code of mine works fine when running on azure-databricks VM's , which means it may be a problem related specifically to how synapse interacts with azure private resources)
I suspect the problem is with the newer/proprietary layers that Microsoft has been putting on top of their VNET's these days (ie. "managed vnets", and "managed private endpoints").  I have noticed other azure services are extremely flakey as well (eg. Power BI's managed-vnet-gateway and ADF pipelines are pretty unpredictable.  I have opened support tickets for both of these as well.)

Would appreciate more details about driver namespace + version + target framework in use, to help us identify, track and unblock you with known issues.

You mean like:

Microsoft.Data.SqlClient v4.1.1
.NET 6
Docker aspnet:6.0-bullseye-slim
Host image: AKSUbuntu-1804gen2containerd-2022.08.29

OK, so going more down the troubleshooting rabbithole and reading up on some things (aspecially in connection with AKS), it seems our issue with this was actually SNAT port exhaustion on the outbound load balancer for the AKS cluster.
Diagnose port exhaustion:
https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-standard-diagnostics#how-do-i-check-my-snat-port-usage-and-allocation
What it looks like:

We have increased the ports per backend instance (to a ridiculously high number :) ) - so we hope to never see this again

Actually, it happened again, and this time without hitting the SNAT limit :(

Since you're able to reproduce the issue in AKS, does it reproduce the exceptions in docker containers or Unix env locally as well?
Would it be possible to share a minimal repro here to investigate?

Came across this website while searching for a solution:
https://support.optimizely.com/hc/en-us/articles/4432366206733-CMS-12-site-crash-due-to-SQL-timeout-error-when-working-in-CMS-edit-mode
Can it be related to ThreadPool.MaxThreads ?
I have not tried to adjust MaxThreads myself yet.

false
4
200
false
same here, this is my config... still happen :( why???

I'm having the same issue. Any solutions?

@maxafu we never got anywhere with it but I'm no longer with the company this was reported on. I believe people there are still watching this issue though.
We were hoping that what @DLS201 told us was true and MS were going to fix it this quarter. Every other avenue of investigation failed basically.

 <ConcurrentGarbageCollection>false</ConcurrentGarbageCollection> <ThreadPoolMinThreads>4</ThreadPoolMinThreads> <ThreadPoolMaxThreads>200</ThreadPoolMaxThreads> <ServerGarbageCollection>false</ServerGarbageCollection>
same here, this is my config... still happen :( why???

I posted a reply in #647 and the TL;DR: it might be related to thread pool starvation and to mitigate that is to increase the ThreadPoolMinThreads as a temp solution, and unfortunately, we currently don't have a fix for it yet.

Turns out our issue was simply a genuine long running (dynamic based on filters the user selects on front end) query hitting the timeout with some filter selections. We has assumed the particular query involved (which happens sporadically) was ok because similar (but not identical) queries were ok. When we intercepted the T-SQL of a query that reached the timeout and re-ran it exactly as is we replicated the timeout and perf issue. Slightly embaressing but there you go - make sure you log the exception and try to intercept the exact T-SQL and re-run it to make sure it's not just a genuine query perf issue ;-)

@dantheman999301
Forgive me for doing this, just wanted to play devils advocate in the small chance it might help (very small) you, or someone else.

DTUs would not budge, which you'd expect if a query was underperforming

In our case, our DTU's were well within limits. The only requirement for this to occur on our side was a query to be "long running" past the timeout set by the client. There is no specific requirement that the query be CPU, IO or memory intensive - although I agree you would assume the two would go hand in hand.

and the queries themselves were incredibly simple and running fine on either side

Suggests you were looking at multiple queries, could it be that the specific query that caused the timeout has a slightly different query plan to the rest (for example this is commonly the case with queries that have IN clauses where the the IN clause portion changes with the values provided from query to query so sql server has to regenerate query plans). The queries themselves may seem simple and alike, but if the query plan is different from invocation to invocation, some specific queries could be drastically different in performance whilst appearing to look similar in nature.

SQL Server also did not report seeing the timeouts which you'd expect for a genuine timeout.

Does SQL Server report timeouts that are due to the client's own timeout settings? I honestly don't know but it would surprise me if it did. When connecting via EF Core (ADO.NET) we set a timeout on the client of 30 seconds. Most queries ran < 1s. Occassionally a very "similar" query would take > 30s and we'd get this timeout. This lead to the illusion that it couldn't possibly be the query itself.
Basically what I'd say is, be sure you've captured a specific query that caused the timeout, and then re-execute it exactly as is to make sure it definitely isn't a perf issue with that query.

@dazinator
SQL Server does report on long-running queries, hence why we assumed that the error was happening at the application level. I don't have the information to hand anymore having left the company but given these were 30+ seconds of waiting, it would have shown up in some of the information tables SQL Server provides.
We spent a considerable amount of time looking into the causes, and it was happening in multiple services for different queries and in different environments, some of which had little to no data that would even cause a 30+ second slowdown.
I understand the need to be thorough but we had run through a lot of the steps you have outlined. I just don't want this ticket to get lost in the ether because people assume it's laziness on our part.

We've had this same issue multiple times. Had a ticket open with Microsoft on the SQL side for weeks, in the end they could not find any long running queries, although we had Application Insights reporting some queries taking over 2 minutes, which is also not possible because our .NET SQL command timeout was set to 30 seconds in most cases, and never more than 1 minute. So they ruled out any SQL issue.
We had a separate ticket open with the App Service team (we run on App Service with Linux Docker containers) - and it also completely stumped them - no issues with threadpool, networking etc. In the end I have had to scale up to many more instances than should be necessary, and the issue has not recurred but each instance is only able to handle about 6 requests per second which is super low, given the average API request response time is under 500ms. So no idea of the root cause of this.

Azure Support just told us that the product group identified the issue and will fix it Q4 2022.

@DLS201 any chance you have more information on this? Maybe a link to a bug or something? We are investigating this issue currently and would like to know what MSFT knows...

Yes, more information would be nice...
We have found exception count to go down in our app after upgrading to 5.1.1 (from 5.0.1 in our case).

In fairness to @DLS201 the support engineers at Microsoft absolutely HATE giving out reference identifiers for their bugs, and they especially don't want to share anything that will be posted on the Internet.  There is no concept of a KB database anymore either, like in the good old days. Microsoft doesn't seem to have a formalized way of sharing the known bugs in the public.  That would be way too helpful.
I suspect that the only information that is available to DLS201 is whatever is being tracked in his own CSS case.  A CSS case number is very customer-specific, and there is probably no way for anyone else to benefit from the investigation that was done.  Unless he was very persistent, he won't get any bug # from the PG or anything useful like that.  The bug # is probably not something the PG would share either.  Probably the best general-purpose identifier for the bug would be the "IcM#" that is used for communication between CSS and the PG.  I've had some luck getting those in the past, and sharing them with others.
I don't know if it helps anyone, but my best guesses are either (1) a DNS overload issue because of misconfigured cache, or (2) a firewall issue on certain ephemeral ports that are infrequently used (ie. certain ports above 64000 or so).  I don't have the issue when running my stuff on-premise - only in someone else's VM's (in a Synapse Spark cluster, for example).  I still get this from time to time, and my Spark jobs need then need to be resubmitted.

Not sure if is the same issue, but Im also seeing this error with System.Data.SqlClient as well in .net core 6 running in linux AKS. Could it be the same underlying issue?
System.Data.SqlClient.SqlException (0x80131904): Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.
 ---> System.ComponentModel.Win32Exception (258): Unknown error 258
   at System.Data.SqlClient.SqlCommand.<>c.<ExecuteDbDataReaderAsync>b__126_0(Task`1 result)
   at System.Threading.Tasks.ContinuationResultTaskFromResultTask`2.InnerInvoke()
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
--- End of stack trace from previous location ---
   at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot, Thread threadPoolThread)
--- End of stack trace from previous location ---
   at Dapper.SqlMapper.QueryAsync[T](IDbConnection cnn, Type effectiveType, CommandDefinition command) in /_/Dapper/SqlMapper.Async.cs:line 418

Since I've struggled with the same issue I will share our findings as well, we had this thoroughly checked one of the most striking things was this only happends on nix containers (tested with a wide variety from debian based over alpine etc) it does not happend on windows machines or Windows containers, strangely we never experienced the issue on our staging system even with load tests the most crucial point was the sql server instance running was the same version as the production one tough it was a Linux host instead a Windows host (or maybe the load tests weren't heavy enough but it's kind of strange) what really mitigated the issue with the nix containers was upgrading the sql instance, we tried a lot of other routes and like switching Sql Client versions etc but it didn't really affect the issue, our suspected root cause of this is probably some difference in the Linux / Windows networking stack but as for now we won't do any further investigations as the sql server upgrade strangely solved the issue somehow, hope this information somehow helps

Just a note to say that despite my comment above about genuine timeouts.. we still experience this issue regularly and have no idea as to the reason / cause. This is the most frustrating part of the issue is even knowing hot to trace it. Expecially when you are using AzureSQL as we do not control that side of the infrastructure. We also run our workloads on Linux docker containers and this being a problem on Linux seems to be a common theme. @eisenwinter were you running on Linux docker containers? Or just directly on Linux VM's?

@dazinator we only tested containers on different Linux host Systems to see if it's possible related to a certain kernel version or not but seems like it's not, as said we stopped testing after the issue disappeared after migrating the sql server to a newer version, just wanted to share our experience maybe it helps others somehow

After struggling with this and a few other issues with Azure SQL, we decided to move to PostgreSQL. I've had enough of SQL Server. Luckily, we were in a position to move away from azure SQL.

I had a similar problem recently, the root cause was the introduction of a TransactionScope -> https://github.com/dotnet/SqlClient/issues/647#issuecomment-1602980797

We are also experiencing this issue with Linux App Services against Azure SQL. We only began seeing this after migrating our App Services from Windows to Linux.

Same boat as others.  In our situation we are using Azure Linux Function App (net6.0<EMAIL_ADDRESS>connecting to an Azure SQL Server.   Db showing no symptoms, vCore levels low.  No long running queries.  Everything was running fine for years... then pop intermittent Unknown error 258 throughout the day.

Yes, we tried upgrading to .NET 7 and the latest SNI package release (5.1.1). It didn't fix it. The only thing that has made any difference was the suggestion to bump the min thread count. We bumped it to 20 and now very rarely see the issue (maybe 1/day or so).
Nothing seems to eliminate it so far but the thread count workaround does help.

To continue the conversation about this issue being related to Linux ... our Application Insight logs show that these random timeouts AND application performance issues all started after Azure East US maintenance upgraded our Azure Function Host from Linux <IP_ADDRESS>-1.cm1 to Linux <IP_ADDRESS>-1.cm2.   No code or db changes on our part, just suddenly the AppInsight logs show kernel 5.15.   @eisenwinter - you said you tried a few different kernels, did you go back to 5.10?  Anyone else seeing this issue on 5.10 or lower?

We lifted to .NET 7 but still see occurrences.

I was in the same problem. My Application was running at Docker in  Redhat VM. Few weeks I struggled with it. After that, I just moved to Windows. And I didn't have any problem.
I doubt the network issue is there in my VM and Database.

I am having the same problem.

System.Data.SqlClient version: 4.8.5
.NET target: .NET 8.0
SQL Server version: Microsoft SQL Server 2019 Developer (64-bit) - 15.0.2101.7
Operating system: Windows Server 2019 Datacenter (10.0)

System.Data.SqlClient.SqlException (0x80131904): Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.
 ---> System.ComponentModel.Win32Exception (258): 待ち操作がタイムアウトになりました。
   at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
   at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
   at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
   at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)
   at System.Data.SqlClient.SqlDataReader.TryConsumeMetaData()
   at System.Data.SqlClient.SqlDataReader.get_MetaData()
   at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)
   at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async, Int32 timeout, Task& task, Boolean asyncWrite, SqlDataReader ds)
   at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, TaskCompletionSource`1 completion, Int32 timeout, Task& task, Boolean asyncWrite, String method)
   at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)
   at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior)
   at System.Data.SqlClient.SqlCommand.ExecuteDbDataReader(CommandBehavior behavior)
   at System.Data.Common.DbDataAdapter.FillInternal(DataSet dataset, DataTable[] datatables, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior)
   at System.Data.Common.DbDataAdapter.Fill(DataTable[] dataTables, Int32 startRecord, Int32 maxRecords, IDbCommand command, CommandBehavior behavior)
   at System.Data.Common.DbDataAdapter.Fill(DataTable dataTable)

The table has 10 columns.
Total number of data is 22,000,000.
When I call "Fill" with PK by SqlCommand, the error occurs only the first time.
On the second call, the correct 10,000 items are retrieved.
It occurs in single-threaded console applications, even when accessed from a single instance.
I believe the problem is not a client application problem, but a database cold start problem.
Is there any way to warm up the database?

@SharePointX have you tried Microsoft.Data.SqlClient? Is this constantly happen on your application? Can you share a sample repro?

I swapped to Microsoft.Data.SqlClient to check and still got the same error.
However, it does not occur on the second run.

1st run: timeout error
2nd time: Normal termination immediately
After restarting SQL Server service: takes a long time but ends normally

The other thing I found out is that the error occurs only when querying a table with a very large number of records in the same DB instance.

@SharePointX have you tried increasing the connection timeout to make sure it won't be timed out while retrieving data from the server and how it affects the execution?
I'd suggest retrieving data in smaller batches if it fails with large portions to find the balance.
If the server is not available temporarily (especially over the network), I'd recommend doing the retry pattern on the the application level with the remaining data.
There are some thread starvation scenarios with thread pool and connection pool, which I believe don't apply to your case with a single-threaded app. I don't have any idea about warming up the database, you may ask the SQL Server Dev team.

I revisited this problem and stumbled upon something intriguing while using EF Core 7.0. I discovered that both DbConnection and DbCommand have a CommandTimeout property.
Here's how I configured the database service:
builder.Services
    .AddDbContext<DatabaseMaintenanceContext>(options =>
    {
        var connectionString = "----";
        options.UseSqlServer(connectionString, sqlServerOptionsAction: sqlOption =>
        {
            sqlOption
                .CommandTimeout((int)TimeSpan.FromMinutes(30).TotalSeconds);
        });
    });

When calling the stored procedure, I had to include the following code:
_db.Database.OpenConnection();
var command = _db.Database.GetDbConnection().CreateCommand();
command.CommandText = "StoredProc";
// command.CommandTimeout = _db.Database.GetCommandTimeout().Value; // The command timeout is not set without this line
return await command.ExecuteNonQueryAsync();

I initially assumed that DBCommand.CommandTimeout was inherited from DBConnection.CommandTimeout, but that's not the case. The line mentioned above must be uncommented. After doing so, the timeout issue (258 timeout) is resolved. This behavior was somewhat unexpected. Is there a better way to handle this configuration?

@oyvost You can set it in the connection string.

To continue the conversation about this issue being related to Linux and to hopefully narrow in on an event ... our Azure Application Insight logs show that these random timeouts AND application performance issues all started after this Azure East US maintenance window QK0S-TC8 did SOMETHING to Azure functions host on August 17th 9:00PM EST. Something in that host update caused this unknown error 258 to start appearing.
At that point in time, our host went from Linux <IP_ADDRESS>-1.cm1 to Linux <IP_ADDRESS>-1.cm2 and application performance tanked shortly after, and we now have the sudden appearance of these Unkown error 258 throwing exceptions. Some metric digging shows that memory usage (P3V3 with 32GBs) tanked along with performance.

No code or db changes on our part, just suddenly the AppInsight logs show kernel 5.15, odd timeout errors, and we presumably can't access memory. @eisenwinter - you said you tried a few different kernels, did you go back to 5.10? Anyone else seeing this issue on 5.10 or lower?
Update: We converted the function app over to Windows. The sql timeout errors are gone and application performance is restored! 🎉

Just want to mention that we experienced a similar issue and converting to Windows seems to have solved the problem.

I can't switch to windows to solve this.
I added polly retries with exponential backoff and on the third retry when this error occurs, the query succeeds. This has allowed us to remain operational thank goodness.

Would it be possible to hear from the SqlClient team as to whether any fixes in the latest release (5.1.2) may help with this issue? https://github.com/dotnet/SqlClient/blob/main/release-notes/5.1/5.1.2.md

If you have chronic problems or outages, please open a support ticket with Microsoft and share the outcome here.  I think that type of information will allow us to proceed more productively.
I'm a "big-data" developer in Azure, and I have suffered from chronic socket exceptions in multiple Azure platforms - just as everyone else is describing.  The main pattern I've noticed is that they happen within Microsoft's proprietary VNET components (private endpoints).  They are particularly severe in multi-tenant environments where several customers can be hosted on the same hardware (or even in containers within the same VM.
The problems are related to bugs in Microsofts software-defined-networking components (SDN proxies like "private endpoints" or "managed private endpoints").  I will typically experience these SDN bugs in a large "wave" that impacts me for an hour and then goes away.  The problems have been trending for the worse over the past year, and I've opened many tickets (Power BI, ADF, and Synapse Spark).
The problems are not likely to happen on normal TCP (public internet ports).  Nor are they common on VNET traffic when "peering" is used.  It seems to be a problem that is specific to the funky private endpoints in Azure.  I would be interested to know if others can related to this pattern?  Also, the socket exceptions are not specific to SQL.  They impact MSAL, ADLS, REST, etc.  The underlying TCP exceptions are generally the same in all cases ("connection reset" or "connection timeout").
The Microsoft support cases I have already opened have not gone well.    I think they are already well-aware of the bugs in their private VNET technology and are trying to keep them hidden.  They undermine the severity of these problems by repeating the word "transient" over and over like it was some sort of a magical incantation that makes the bugs more acceptable. To me it seems totally unacceptable to have issues (transient or otherwise) that trigger dozens and dozens of socket exceptions a day.
I find that there are lots of Microsoft's own products that are impacted by these network bugs, notably ADF pipelines.  They have had a "VNET IR" that suffers from a massive number of socket exceptions when interacting with resources in the local network (East US).  The support teams actually say they have a formalized "policy" to require customers to implement retries on all pipeline activities (they suggest at least three retries with two minute delays in between them).  This "policy" is simply a way to avoid the well-known bugs.  ADF deployed the VNET IR several years ago and they have probably handled hundreds of CSS tickets about the fragile private endpoints in their managed vnet.
IMPORTANT: Based on a three-year support case with another team (not ADF) I do have bug numbers that apply to private endpoints and these bugs are supposed to be fixed soon (not holding my breath).
The following changes are for the "Azure Network stack":
Feature ending with x509 : Support map space deletion in VFP without breaking flows.
(virtual filtering platform, ie switch?)
The ETA publicized is late 2024
Bug ending with x810 : PE-NC Flow mix up
Network team promised to roll it out early 2024.
Sorry for the long post.  I think it is easy for everyone to prove that these problems are specific to Azure, and don't affect on-premise scenarios with Sql Client.  The challenge is getting Microsoft to help with them in Azure.  I get the sense that there is a substantial lack of honesty and transparency when it comes to networking bugs in Azure.  There was only one support scenario where Microsoft was willing to admit to the bugs I've experienced in their SDN technology.  In every other Azure platform they are refusing to investigate or discuss the so-called "transient" network errors that cause TCP connections to break between resources that are in direct proximity to each other (0 ms latency).
Here is a discussion of ADF's networking bugs.
https://learn.microsoft.com/en-us/answers/questions/1390627/what-is-the-reason-for-networking-problems-in-adf
Hope this helps.  I would appreciate it if those impacted by the socket errors would at least confirm that their scenarios involve VNETS, eg. private endpoints in particular, and possibly managed vnets.  If you open a support case with Microsoft, please keep a count of the number of times they use the word "transient" (and they always say "communication failure" rather than socket exception).

If you have chronic problems or outages, please open a support ticket with Microsoft and share the outcome here. I think that type of information will allow us to proceed more productively.

We did this. It was punted around between teams with no resolution so we closed it on our side because we were tired of spending time answering the same questions over and over. The workarounds posted here have helped but not eliminated the issue. We decided to stick with *nix App Service instances although the time spent futzing around on this issue has cost us more than the savings switching from Windows instances.

The main pattern I've noticed is that they happen within Microsoft's proprietary VNET components (private endpoints). They are particularly severe in multi-tenant environments where several customers can be hosted on the same hardware (or even in containers within the same VM.

@dbeavon We have a multi-tenant application running as a docker container on an Azure VM - connecting to SQL azure over a private endpoint which presents itself as a nic on the vnet. So yes I think this is a good match.
I have not tried deleting the private endpoint and going via the public ip, i will give that a shot.
As it stands, we are mid plan refactoring our application to make our most impacted SQL calls in a newly dedicated process (theory being it was something to do with thread pool ramp up when other things are sharing the thread pool). So by giving our task a dedicated dotnet process hopefully that will help. However if it doesn't, aside from being really annoyed, atleast I can give the public IP a go..

@dazinator I certainly agree about the pain of support.  But if Microsoft isn't working on these sorts of cases, then they will have less motivation to fix the underlying bugs .  I doubt there is any telemetry that is captured for the so-called "transient" socket exceptions in their virtualized  network technology.   If only 1% of the impacted customers are making the effort to report these problems then Microsoft probably thinks the problems aren't very severe.
And if Microsoft won't prioritize or fix these network bugs, they will impact us forever.  Just as a case in point - the managed-vnet-IR in ADF has been buggy for ~4 years.  And the managed vnet gateway in Power BI is also impacted by the same private endpoint bugs for ~3 years (the only difference here is that the Power BI team wisely allowed their component to remain in a "preview" state rather than pushing ahead with a premature GA).   I have had a case open with the PBI team for the entire time this component has been in preview.
The biggest pain for me has been with the Synapse platform.  Hosting my Spark workloads on Synapse has been a real nightmare.  I see dozens and dozens of socket exceptions each day, in every possible type of remote connection.  However this did NOT happen to me when my Spark workloads were hosted on Azure Databricks (using an injected VNETs, rather than private endpoints).  Nor do I see these socket exceptions when running a standalone Spark cluster on my own local hardware.  It is pretty easy to distinguish the network environments that work fine from the ones that are bug-ridden.  There is no excuse for the unreliable nature of Microsoft VNETs.  The TCP transport protocol is already designed to be fault-tolerant.  Microsoft has really changed the whole equation when it comes to the reliability of TCP connections....
It is especially annoying to think about the fact that these failed connections are taking place between servers that are sitting a hundred yards from each other (or less).  ... I will have to find the Azure East US region on google earth to see how big it is.  It is certainly not big enough to suffer from "random Internet glitches".  I would have better network reliability running my Spark clusters on the Wifi at an airport than I would in Azure!

@dbeavon -  I know how painful an impossible it can be to track down transient network errors.  I bet the MS team does too, hence the run around.  Transient errors stink, I feel your pain.
I do want to point out that this particular situation could or could NOT be related to network errors.  We experienced that the Intermittent Unknown error 258 began with an update to our Linux App Service that clearly changed it's operating telemetry and then this error appeared.
We'll all need to work together to get this one sorted.

It doesn't help that 258 seems to be used for a wide range of problems. Your query is slow? Unknown error 258. The network is congested? Unknown error 258. The DBA didn't like the way you looked at him? UNKNOWN ERROR 258.

The main pattern I've noticed is that they happen within Microsoft's proprietary VNET components (private endpoints). They are particularly severe in multi-tenant environments where several customers can be hosted on the same hardware (or even in containers within the same VM.

@dbeavon We have a multi-tenant application running as a docker container on an Azure VM - connecting to Azure SQL over a "private endpoint" (which presents itself as a nic on our vnet). So yes I think this is a good match.
I have not tried deleting the private endpoint and going via the public ip, i will give that a shot. As it stands, we are mid plan refactoring our application to make our most impacted SQL calls in a newly dedicated process (theory being it was something to do with thread pool ramp up when other things are sharing the thread pool - and this not playing well with the was sql client library is written using sync over async and such). So by giving our task a dedicated dotnet process hopefully that will help. However if it doesn't, aside from being really annoyed, atleast I can give the public IP a go..
It's too painful to go through support, we are a small team and the level of time required to get this over the line appears too much.

We went the other way, from public IP to private endpoint, if my memory serves me, it was after some we advice received from azure support when we asked to investigate it. It did not help much.
What did seem to help (a bit, we still get frequent timeouts / 258), is to have less applications / concurrency on a single 'vm' by making our 'apps' reserve more cpu's (on k8s) even thought they do not really need it when looking at the cpu usage.

It would be very easy to send a repro to one of these Azure teams, but they are always unwilling to pursue that option.  I have a couple tickets open at the moment where I offered to give the CSS engineers a repro in order to experience these problems for themselves, and they are totally uninterested in taking that path.
(It is strange to behold a vendor that doesn't care about fixing their bugs.  When using on-prem software, vendors are typically VERY appreciative if you could provide a consistent reproducible that allowed them to independently review a bug on demand.)
In my experience this problem isn't specific to SQL.  In my Synapse-Spark clusters I have chronic socket failures in Azure across a number of remotely accessed services (MSAL, REST, SQL, etc).  I just finished up with a support case involving the ADF team whereby they were experiencing a similar problem in their own component (ADF "Linked Service Resolver").  Their component was very unreliable as it was making connections to MSAL from the managed vnet.  This particular MS team (that is responsible for the ADF "Linked Service Resolver") says the solution is that every TCP socket which is opened in Azure needs to be wrapped in retry loops that are repeated five times with two minute delays between them.  I'm not sure about you folks but it seems absurd.  The TCP protocol is supposed to be resilient and fault tolerant, so that application developers don't need to re-invent the wheel and wrap a ton of custom retry logic around every remote TCP connection.
In the end, the ADF team "mitigated" their own component ("Linked Service Resolver") in some way - presumably by using a custom-written retry loop.  Then they closed the case without giving any explanation for the elevated number of socket exceptions that were affecting us in the first place.   I had hoped to learn from the experience and apply the information to the other types of failing sockets, but this ADF team really didn't give me anything useful as a take-away.  Aside from my chronic socket exceptions in ADF/Synapse, I also have frequent outages that are hitting my service-health dashboard.  The outages last thirty minutes at a time and come up on a monthly basis, and these outage notifications often use the word "transient communication failures" to explain the RCA.  In other words, I think Microsoft product teams are suffering from the network problems themselves, even to the point of publicizing them when they become extreme.  Hopefully they will eventually fix these problems for their own sake, (if not for ours.)

For those moving to PostgreSQL to mitigate these issues, what are you using for the migration from MS SQL to PostgreSQL?

The issue can be easily reproduced by running an aspnet core web api project in a Linux container and making multiple concurrent calls to an endpoint to query a SQL Server database immediately after the service starts. The cost of opening each new thread on Linux appears to be very high, and making 30 concurrent queries with no available threads in the thread pool can take more than 60 seconds. If you do the same test running the service on Windows, it works perfectly.
The only workaround for us to get this to work on Linux is to set the ThreadPool.MinThreads to a high number.

Could you please let me know what was the value of min threads you had set as a workaround?

@asierpn @dazinator @MichelZ Could you please let me know what was the value of min threads you had set as a workaround?

It depends on your application, you have to test with different values to find the best one for you, we noticed an improvement when we set it to 20, but eventually we increased it to 100.

So here is a dotnet application that is run as a docker container on an azure VM (ubuntu), it starts up and does some EF Core queries.
You can see in these logs that it "times out" after every 2 second retry. I also print basic thread pool info at that point - note that "Pending tasks" is 0.

Here is the azure sql database metrics at this time

I can see there is a spike at this time, but nothing seems to be maxing out..
The error 258 is returned almost immediately, certainly not a 30s timeout, but if the queries aren't making it to the sql server then why does it spike inn usage at this time..

Just want to clarify one misconception.

The cost of opening each new thread on Linux appears to be very high, and making 30 concurrent queries with no available threads in the thread pool can take more than 60 seconds.

While the cost of creating new threads is higher on Linux than on Windows, for example. It's not that cost that slows things down. The system thread pool implementation in .NET is designed to spin up new threads slowly, in a very conservative manner. If a library or application is spawning many tasks that hold threads for any length of time, it will take a while for the system thread pool to add threads to service the waiting queue of tasks.

@DerPeit glad you solved your issue.

I hope this helps some of you guys and I'd be interested if the other things you tried might correlate with our observation

On this point, I think what you saw and what we saw were different issues. We never saw these queries make their way to the database, or at least not that we could find. The queries themselves would not have been long-running (e.g. selecting a single record by ID) and they could happen when the DB was using less than 10% DTUs.