sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: storybook
Issue: [Bug]: Docs stories filtered with `'!autodocs'` behaves weird in `Primary`, `Stories`, `Controls`, etc. components
Labels: bug,addon: docs,tags,sev:S3

### Describe the bug

In 8.1, we introduced the `autodocs` tag per story. It introduces a slightly inconsistent behavior:

1. ~The `Stories` doc block automatically filters out any stories that don't have `'autodocs'` - even if it is in a _manually_ written attached MDX. Is that weird?~ Somewhat fixed in https://github.com/storybookjs/storybook/pull/27144
2. The `Primary` doc block doesn't take the filter into account at all, meaning that if the primary story has `'!autodocs'` it will still be selected as the primary story. Should it?
3. 👆 Same for `Controls` and any other doc block supporting primary stories.
4. `useOf` and `resolveOf` doesn't do any automatic filtering, causing the issue with 2 and 3 above. We briefly explored filtering out all `'!autodocs'` stories internally in `DocsContext` to solve all problems above, but that wasn't the best idea. It would make it impossible to resolve a story with `'!autodocs'` in a manual MDX, which seems counter intuitive.

I don't know what the right solution is here, or if there even is any, but we should be aware of this.

### Additional context

@shilman proposes that all Storybook-provided doc blocks should automatically filter out `'!autodocs'` stories - even when used manually in MDX/DocsPage, S a way for users to easily re-create the autodocs experience.
But all user-written doc blocks (those that use `useOf()` or `resolveOf()`) should not do automatic filtering. Instead we should provide the tools to apply a filter if needed, either by passing a `filter: true` boolean somewhere, or make the filter function easily accessible.
Repository: kubernetes
Issue: Failing test due to pv expecting a "topology.gke.io/zone" label that is not set in OSS kubernetes nodes on GCE
Labels: sig/storage,kind/failing-test,sig/cloud-provider,triage/accepted

### Which jobs are failing?

autoscaling e2e test: Kubernetes e2e suite.[It] [sig-autoscaling] Cluster size autoscaling [Slow] should increase cluster size if pod requesting volume is pending [Feature:ClusterSizeAutoscalingScaleUp]

### Which tests are failing?

Kubernetes e2e suite.[It] [sig-autoscaling] Cluster size autoscaling [Slow] should increase cluster size if pod requesting volume is pending [Feature:ClusterSizeAutoscalingScaleUp]

### Since when has it been failing?

Not sure, it is failing for the whole time in the testgrid

### Testgrid link

https://testgrid.k8s.io/sig-autoscaling-cluster-autoscaler#gci-gce-autoscaling

### Reason for failure (if possible)

The scheduler rewrites the PV requirements from InTree to CSI requiring a label "topology.gke.io/zone" that is not set on nodes that are running in OSS kubernetes (started with kube up script).

Starting the cluster command:
kubetest2 gce -v 2   --repo-root ~/src/k8s.io/kubernetes   --gcp-project <project name>   --legacy-mode --build --up --env=ENABLE_CUSTOM_METRICS=true --env=KUBE_ENABLE_CLUSTER_AUTOSCALER=true --env=KUBE_AUTOSCALER_MIN_NODES=3 --env=KUBE_AUTOSCALER_MAX_NODES=6 --env=KUBE_AUTOSCALER_ENABLE_SCALE_DOWN=true --env=KUBE_ADMISSION_CONTROL=NamespaceLifecycle,LimitRanger,ServiceAccount,ResourceQuota,Priority --env=ENABLE_POD_PRIORITY=true

The problematic code seems to be here: https://github.com/kubernetes/csi-translation-lib/blob/master/plugins/gce_pd.go#L257

I see what is the problem, but it is not clear for me what should be the correct behavior. It seems that in GKE this label is actually set on the node.

The labels that I see on the node of my cluster:
                    beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/instance-type=e2-standard-2
                    beta.kubernetes.io/os=linux
                    cloud.google.com/metadata-proxy-ready=true
                    failure-domain.beta.kubernetes.io/region=us-central1
                    failure-domain.beta.kubernetes.io/zone=us-central1-b
                    kubernetes.io/arch=amd64
                    kubernetes.io/hostname=kt2-1b77b5e4-87ae-minion-group-5pgr
                    kubernetes.io/os=linux
                    node.kubernetes.io/instance-type=e2-standard-2
                    topology.kubernetes.io/region=us-central1
                    topology.kubernetes.io/zone=us-central1-b


What the test is doing:
- the test creates a PD on GCE 
- connects a PV to it
- creates a PVC 
- tries to schedule a pod that requires this PV

### Anything else we need to know?

_No response_

### Relevant SIG(s)

/sig-storage
Repository: Web-Dev-For-Beginners
Issue: Deployment Failure in 7-bank-project
Labels: no-issue-activity


 Azure Static Web Apps CI/CD / Build and Deploy Job (push) Failing after 3m in 7-bank-project


Steps to reproduce the behavior:
1. You can go to the repo microsoft/Web-Dev-For-Beginners
2. Then go to the 7 banks project
https://github.com/microsoft/Web-Dev-For-Beginners/tree/main/7-bank-project
3. On the headder you will find and cross mark if you click it you can find the deployment failure log
4. But you can find the error log as its expired

**Expected behavior**
There should be a tick mark which should say that the deployment was sucessful

**Screenshots**

![image](https://github.com/microsoft/Web-Dev-For-Beginners/assets/91420331/c5003ab6-c780-4998-a5bd-a7d2e6151bbc)

![image](https://github.com/microsoft/Web-Dev-For-Beginners/assets/91420331/f63d2113-9afb-47fe-8210-e0418a0f2db5)

![image](https://github.com/microsoft/Web-Dev-For-Beginners/assets/91420331/97501f84-4d1f-4ee6-90c8-f4ceda335998)

![image](https://github.com/microsoft/Web-Dev-For-Beginners/assets/91420331/ffd62c8e-a369-4559-8135-e0f1c741637b)


**Desktop (please complete the following information):**
 - OS: Windows 11 Version	10.0.22631 Build 22631
 - Browser Google Chrome     Version 124.0.6367.119 (Official Build) (64-bit)
Repository: stable-diffusion-webui
Issue: [Feature Request]: Is it possible to queue batch img2img with a new prompt for each image? 
Labels: enhancement

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What would your feature do ?

For batch img2img, it currently takes the first image and goes through every prompt for that image and then goes to next image. What I want is the second image with the second prompt, third image with the third prompt, etc.

### Proposed workflow

1. Go to img2img
2. In Scripts we select "Prompts from file or textbox" 
3. Add a checkbox "One image per prompt"
If we tick this then only one image per prompt is generated, it doesn't matter how many img2img images are present in batch folder, when prompts end the generation should end. 
In case img2img batch images end and prompts remain then we can loop back to same images present in the folder.

Something like this

### Additional information

_No response_
Repository: next.js
Issue: Error occurred prerendering page "/_not-found" with pageExtensions option
Labels: bug

### Link to the code that reproduces this issue

https://codesandbox.io/p/devbox/misty-glade-yh92cc

### To Reproduce

After update to 14.2.* version, when i use `pageExtensions` in `next.config`, i got an error while try to build my app
```
module.exports = {
  pageExtensions: ['page.tsx', 'page.ts'],
}
```
i have in my `app`  folder all files with `.page.tsx` - 

```
app:
- error.page.tsx
- global-error.page.tsx
- not-found.page.tsx
- layout.page.tsx
- page.page.tsx
```



### Current vs. Expected behavior

Build app fail with `pageExtentions` option

```
✓ Linting and checking validity of types    
 ✓ Collecting page data    
   Generating static pages (0/8)  [=   ]
Error occurred prerendering page "/_not-found". Read more: https://nextjs.org/docs/messages/prerender-error

TypeError: Cannot read properties of undefined (reading 'clientModules')
    at /home/ui/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:16:23603
    at /home/ui/node_modules/next/dist/server/lib/trace/tracer.js:191:62
    at /home/ui/node_modules/next/dist/server/lib/trace/tracer.js:140:36
    at NoopContextManager.with (/home/ui/node_modules/@opentelemetry/api/build/src/context/NoopContextManager.js:25:19)
    at ContextAPI.with (/home/node_modules/@opentelemetry/api/build/src/api/context.js:60:46)
    at NoopTracer.startActiveSpan (/home/ui/node_modules/@opentelemetry/api/build/src/trace/NoopTracer.js:65:31)
    at ProxyTracer.startActiveSpan (/home/ui/node_modules/@opentelemetry/api/build/src/trace/ProxyTracer.js:36:24)
    at /home/ui/node_modules/next/dist/server/lib/trace/tracer.js:122:103
    at NoopContextManager.with (/home/ui/node_modules/@opentelemetry/api/build/src/context/NoopContextManager.js:25:19)
    at ContextAPI.with (/home/ui/node_modules/@opentelemetry/api/build/src/api/context.js:60:46)
 ✓ Generating static pages (8/8)

> Export encountered errors on following paths:
	/_not-found/page: /_not-found

```

### Provide environment information

```bash
Operating System:
  Platform: linux
  Arch: x64
  Version: #29~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Apr  4 14:39:20 UTC 2
  Available memory (MB): 15622
  Available CPU cores: 12
Binaries:
  Node: 20.12.2
  npm: 10.5.0
  Yarn: 1.22.19
  pnpm: N/A
Relevant Packages:
  next: 14.2.3 // Latest available version is detected (14.2.3).
  eslint-config-next: 14.2.3
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.4.5
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

Not sure

### Which stage(s) are affected? (Select all that apply)

next build (local)

### Additional context

_No response_
Repository: godot
Issue: Disabling the Godot script editor does not automatically disable the loading of dominant scripts on scene change.
Labels: bug,topic:editor,needs testing

### Tested versions

- Tested and reproducible in v4.2.1.stable.mono.official

### System information

Godot v4.2.1.stable.mono - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1060 3GB (NVIDIA; 31.0.15.3623) - Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz (4 Threads)

### Issue description

When disabling the godot engine's script editor through Editor > Manage Editor Features, the editor continues to open up files automatically. This is particularly annoying if you are working with an external IDE, as you will continue to get popups from script files asking if they should reload.

When switching between scenes, the script editor will randomly open code files. This is annoying in of itself, but when the script editor is disabled this makes it impossible to go and close those scripts.

I should note that this only appears to happen if the script is in the root node of a scene, but it is incredibly annoying and is driving me nuts.

### Steps to reproduce

- Create a script file
- Create 2 scenes
- Add the new script to the root of the first scene.
- Close the script in the script editor if it is open.
- Switch between different scene tabs and the file will re-open itself.
- Close the file in the script editor
- Go to editor > manage editor features
- Disable the script editor
- Switch between scenes
- Edit the script in an external editor
- A popup will appear asking what action you would like to take.

### Workaround

Disable `open_dominant_script_on_scene_change`
**OR**
Enable `use_external_editor`

These will completely fix the issue, however I am leaving this issue open since if the script editor is disabled then all functionality of the script editor should be disabled regardless of if you have the setting to open dominant scripts or not. If you have disabled the script editor, then you would never want the Godot script editor to open up files in the background as you can never close them again.

### Minimal reproduction project (MRP)

[Reproduction.zip](https://github.com/godotengine/godot/files/15234955/Reproduction.zip)
Repository: kubernetes
Issue: The event is not obtained from the apiserver cache
Labels: kind/support,sig/api-machinery,triage/accepted

### What happened?

When /api/v1/namespaces/sop/events is requested, data is obtained from etcd instead of the apiserver cache. When there are too many events, etcd memory increases.

### What did you expect to happen?

We expect that when /api/v1/namespaces/sop/events is requested, data is also fetched from the apiserver cache

### How can we reproduce it (as minimally and precisely as possible)?

Request /api/v1/namespaces/sop/events. Check the etcd logs. It is found that data is directly obtained from etcd instead of apiserver cache.

### Anything else we need to know?

_No response_

### Kubernetes version

<details>

```console
$ kubectl version
# 1.28
```

</details>


### Cloud provider

<details>

</details>


### OS version

<details>

```console
# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here
```

</details>


### Install tools

<details>

</details>


### Container runtime (CRI) and version (if applicable)

<details>

</details>


### Related plugins (CNI, CSI, ...) and versions (if applicable)

<details>

</details>
Repository: vscode
Issue: Debugger: Collapse multiline values in variable pane preview
Labels: bug,debug

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

In the debugger variable pane, VSCode shows a truncated, single line preview of the value returned in the DAP Variable type. It would often be more useful to show more than just the first line, and it is further confusing that when the first line is shorter than the width provided, no ellipsis is shown, so that it is unclear that there is actually a second line.

For example, if the DAP value is something like:
```
{
  "name":"city",
  "value":"criterion_id: 1\ncountry_code: \"DE\"\ncity_name: \"chicago\"\n"
  ...
}
```

Currently we show this: 
![just "criterion: 1"](https://github.com/microsoft/vscode/assets/29040/40c562f1-0ab6-4ce5-a45a-50c90fe95f19)
 
I think it would be more useful to not use `white-space: pre`, so that instead we show:
![image](https://github.com/microsoft/vscode/assets/29040/ad2d3dba-4234-4f1c-ba1a-ecc397f0de97)

First, if there is more space, it is used. Second, there is always an ellipsis symbol when something was cut off, not just if there is something cut off in the first line.

Happy to send a PR deleting the `white-space: ellipsis` if you agree this is an improvement.
Repository: ollama
Issue: Degraded response quality on v 0.1.33
Labels: bug,performance

### What is the issue?

I have an application that creates summaries of text and noticed that  -  after upgrading to v0.1.33 - the quality of the generated content was MUCH worse, without any change in the code or model.

- in some summaries it seemed that the model would not respect instructions, and would be extremely verbose
- in some cases, the model seemed to hallucinate , and provide opinions that did not reflect the content that was summarized.


I rolled back to 0.1.32, and the responses immediately went back to normal.

This is running on docker, in a UBUNTU 22.04 VM with 128G RAM (no gpu), and the model I have been using is dolphin-mistral:v2.6.

Anyone else experienced something similar?

It "looks" like Ollama was using a completely different  model (that machine has a few installed) or that it wasn't allocating enough resources for the model to perform (these are just impressions)

### OS

Linux

### GPU

Intel

### CPU

Intel

### Ollama version

0.1.33
Repository: TypeScript
Issue: Type printing does not detect that a name is shadowed in the current scope
Labels: Bug,Help Wanted

### 🔎 Search Terms

global shadowed declarations 

### 🕗 Version & Regression Information

- This is the behavior in every version I tried, and I reviewed

### ⏯ Playground Link

[Playground Link](https://www.typescriptlang.org/dev/bug-workbench/?target=7&ts=5.5.0-dev.20240507#code/PTAEAEGcBcCcEsDG0Bco4FcCmAoEEATLRAGwENYzp4B7AOzU133GgoHMtVQtIAmAAyCceMOABm8EljpkAtljRkAdNEg4sADwAONWNFCJ6MUDVABeUAG8A2gGUAnnIBGNEsvjQslaHoC6aACMAL4iLJLSsgpozqrq8HK6+tamoMGg4rA0cqAARMrAZLkA3Bo6egakZJCQoI4ubimhWkmVxgbsFqbFQA)

### 💻 Code

```ts
// @strict: true
// @declaration: true
// @target: es2020

// @filename: a.ts
export const o = {[Symbol.iterator]: 1}

// @filename: b.ts

import { o } from "./a";
export class Symbol { }
export const g = o;
```


### 🙁 Actual behavior

The typeof of `g` is `{ [Symbol.iterator]: number; }`. This leads to an incorrect declaration since `Symbol` is shadowed in the current scope

### 🙂 Expected behavior

The typeof of `g` is `{ [globalThis.Symbol.iterator]: number; }`. 

### Additional information about the issue

_No response_
Repository: go
Issue: net: listening on dual-stack UDP socket sometimes silently fails on macOS
Labels: OS-Darwin,NeedsInvestigation

### Go version

go version go1.22.0 darwin/arm64

### Output of `go env` in your module/workspace:

```shell
GO111MODULE=''
GOARCH='arm64'
GOBIN=''
GOCACHE='/Users/marten/Library/Caches/go-build'
GOENV='/Users/marten/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/marten/src/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/marten/src/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/Users/marten/bin/go1.22ex'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/Users/marten/bin/go1.22ex/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.22.0'
GCCGO='gccgo'
AR='ar'
CC='clang'
CXX='clang++'
CGO_ENABLED='1'
GOMOD='/Users/marten/src/go/src/github.com/quic-go/udp-test/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/q0/b5ynf00142l7bl9sp8y098zr0000gn/T/go-build1330860487=/tmp/go-build -gno-record-gcc-switches -fno-common'
```


### What did you do?

I start a dual-stack UDP listener:
```go
net.ListenUDP("udp", &net.UDPAddr{IP: net.IPv4zero, Port: 0})
```
Then I send a UDP datagram (from localhost) to this listener and assert that this packet is received. At the same time, I capture all traffic on localhost using Wireshark.

https://gist.github.com/marten-seemann/bfa811133331b9c053137fd5df12638d

### What did you see happen?

Running the test 10000 times, I pretty reliably get a test failure on macOS. The datagram is sent (as confirmed by the Wireshark trace), but it never arrives at the listener.

This is not caused by UDP packet loss (which shouldn't happen on localhost anyway). To make sure that this is not the cause of the problem, I added another test (`TestUDPUnconnectedDualStackWithRetransmission`), which retransmits the  datagram up to 50 times.

---

This bug is the source of a lot of flakiness in [quic-go](https://github.com/quic-go/quic-go)'s test suite. We're running **a lot** of UDP transfers to test all facets of the protocol, enough to hit this bug on every other CI run or so.

### What did you expect to see?

I expect the packet to be received reliably. This test should never fail.
Repository: next.js
Issue: Multiple loading.tsx files causes extra transition when revalidating with server actions on 14.2.x+
Labels: bug,Navigation

### Link to the code that reproduces this issue

https://github.com/Xexr/revalidate-bug

### To Reproduce

`npm install` to install all dependencies.
`npm run dev` to start the server.

Open [http://localhost:3000/example](http://localhost:3000/example) with your browser

Click the button and you will see that a loading transition is briefly shown on the first press but not on any subsequent presses. This behaviour didn't previously occur with 14.1.4, the first press (and subsequent presses) would revalidate the data without any loading transitions.

The effect in a bigger application is that when a user first invokes a server action, they get a jarring 'refresh' where previously they didn't.

This now appears to happen where multiple layout.tsx and loading.tsx files are present. Remove one of the loading.tsx files and you will see that behaviour reverts to the expected behaviour. I'm not sure if this is part of the root cause, or just masking it by removing a transition.

You can see a vercel deployed example here:

https://revalidate-bug-nine.vercel.app/example

### Current vs. Expected behavior

**Current (the problem)**

With Next 14.2.x+, when I click the revalidate button, the loading icon now appears for the first press.

Hard refresh (F5) to see the behaviour again.

**Expected behavior**

Previously, with Next 14.1.4, when I clicked the revalidate button, the data would revalidate 'behind the scenes' and no loading icon would show for the first press or subsequent presses.

### Provide environment information

```bash
Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP Thu Jan 11 04:09:03 UTC 2024
  Available memory (MB): 15946
  Available CPU cores: 32
Binaries:
  Node: 20.12.2
  npm: 10.5.0
  Yarn: N/A
  pnpm: 8.12.1
Relevant Packages:
  next: 14.2.3 // Latest available version is detected (14.2.3).
  eslint-config-next: 14.2.3
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.4.5
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

Navigation

### Which stage(s) are affected? (Select all that apply)

next dev (local), next build (local), next start (local), Vercel (Deployed)

### Additional context

Works as expected on 14.1.4

Bug appears to be introduced from 14.2.x onwards
Repository: rust
Issue: Documentation differ when Rust is build on i386 Solaris vs SPARC Solaris
Labels: T-rustdoc,A-docs,C-bug,T-libs

On i386 Solaris it contains following files which are not generated for SPARC Solaris:

```
usr/share/doc/rust/html/core/arch/aarch64/fn\.v.*\.html
usr/share/doc/rust/html/core/arch/aarch64/struct\.(f|i|p|u).*
usr/share/doc/rust/html/core/arch/arm/fn\.v.*\.html
usr/share/doc/rust/html/core/arch/arm/struct\.(f|u?int64|u?int32|u?int16x4|u?int16x8|u?int8x16|u?int8x8|p).*
usr/share/doc/rust/html/core/core_arch/aarch64/neon/fn\.v.*\.html
usr/share/doc/rust/html/core/core_arch/aarch64/neon/generated/fn\.v.*\.html
usr/share/doc/rust/html/core/core_arch/aarch64/neon/struct\.(f|i|p|u).*
usr/share/doc/rust/html/core/core_arch/arm/neon/fn\.v.*\.html
usr/share/doc/rust/html/core/core_arch/arm_shared/crypto/fn\.v.*\.html
usr/share/doc/rust/html/core/core_arch/arm_shared/neon/generated/fn\.v.*\.html
usr/share/doc/rust/html/core/core_arch/arm_shared/neon/fn\.v.*\.html
usr/share/doc/rust/html/core/core_arch/arm_shared/neon/struct\.(f|i|p|u).*
usr/share/doc/rust/html/src/core/portable-simd/crates/core_simd/src/vendor/x86\.rs\.html
usr/share/doc/rust/html/src/core/stdarch/crates/core_arch/src/aarch64/neon/.*
usr/share/doc/rust/html/src/core/stdarch/crates/core_arch/src/arm_shared/crypto\.rs\.html
usr/share/doc/rust/html/src/core/stdarch/crates/core_arch/src/arm_shared/neon/.*
usr/share/doc/rust/html/src/core/stdarch/crates/core_arch/src/arm/neon\.rs\.html
```

On the other hand SPARC Solaris contains following files with are not generated for i386 Solaris:

```
usr/share/doc/rust/html/std/os/linux/raw/arch/fn.stat.html
usr/share/doc/rust/html/std/os/linux/raw/fn.stat.html
```

This is causing some problems during packaging. But mainly I would like to know why is this happening...

The above files are valid with Rust 1.78 but previous versions did have similar issues.