sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: next.js
Issue: vary header can't be overwritten even defined explicitly in middleware
Labels: bug

### Link to the code that reproduces this issue or a replay of the bug

https://github.com/yanv1991/cache-control/

### To Reproduce

- start application in prod mode.
- open browser devtools in the root page
- go to network tab and look for the html document at the very top level, click on it
- look for response headers (vary)



### Current vs. Expected behavior

current result:
- vary is not being set(overwritten), even when we set this in middleware file using dynamic rendering

![Screen Shot 2023-09-14 at 11 55 27 AM](https://github.com/vercel/next.js/assets/3800032/3757cc82-dde0-4e5d-9735-c7de7edd9426)

expected result 
- vary should be defined in response header according to the value set in middleware file

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
Operating System:
      Platform: darwin
      Arch: x64
      Version: Darwin Kernel Version 20.6.0: Thu Jul  6 22:12:47 PDT 2023; root:xnu-7195.141.49.702.12~1/RELEASE_X86_64
    Binaries:
      Node: 16.14.2
      npm: 8.5.0
      Yarn: 1.22.19
      pnpm: N/A
    Relevant Packages:
      next: 13.4.20-canary.28
      eslint-config-next: 13.4.19
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 5.2.2
    Next.js Config:
      output: N/A
```


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

App Router

### Additional context

we need to define this vary to be passed to our cdn in order to cache effectively
Repository: storybook
Issue: [Bug]: Storybook init forces to install latest npm 10 at the end
Labels: bug,needs triage

### Describe the bug

When I call `npx storybook@latest init --package-manager npm`, it bootstraps everything 👍. But at the end, it wants to install latest npm - currently npm 10.x - globally. Why? Even when I type 'no', it crashes. 
But later I can start storybook.

I don't want to install any npm by Storybook. It's my responsibility and Storybook itself uses current installed npm for its own bootstrap.

### To Reproduce

see the result from command line, I delete some not important parts
```
> sb-simple-setup@1.0.0 init
> npx storybook@latest init --package-manager npm

Need to install the following packages:
  storybook@7.4.1
Ok to proceed? (y) y

 storybook init - the simplest way to add a Storybook to your project.

 • Detecting project type. ✓
 • Preparing to install dependencies. ✓
 
up to date, audited 13 packages in 940ms

found 0 vulnerabilities
. ✓
√
We were not able to detect the right builder for your project. Please select one: » Webpack 5       
  √ Getting the correct version of 9 packages
  √ Installing Storybook dependencies
. ✓
 • Preparing to install dependencies. ✓
 
up to date, audited 1165 packages in 2s

202 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities
. ✓

attention => Storybook now collects completely anonymous telemetry regarding usage.
This information is used to shape Storybook's roadmap and prioritize features.
You can learn more, including how to opt-out if you'd not like to participate in this anonymous program, by visiting the following URL:
https://storybook.js.org/telemetry

╭──────────────────────────────────────────────────────────────────────────────│                                                                              │
│   Storybook was successfully installed in your project! 🎉                   │
│   To run Storybook manually, run npm run storybook. CTRL+C to stop.          │
│
╰──────────────────────────────────────────────────────────────────────────────
Running Storybook
Need to install the following packages:
  npm@10.1.0
Ok to proceed? (y) n
```
After I type 'n' it crashes
```
npm ERR! canceled
npm ERR! A complete log of this run can be found in: C:\Users\mkubelik\AppData\Local\npm-cache\_logs\2023-09-14T15_47_47_105Z-debug-0.log
```

### System

```bash
currently storybook 7.4.1
```


### Additional context

_No response_
Repository: vscode
Issue: Copy from terminal now adds linebreaks on where text is wrapped
Labels: bug,windows,confirmation-pending,terminal-process

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes/No

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
- VS Code Version: 1.82.0
- OS Version:  Windows_NT x64 10.0.19044

Steps to Reproduce:

1. Open up a terminal
2. Print some long text without line breaks, the text needs to be longer than current window's line width so that it'll be wrapped by vscode. (e.g. `echo ssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss`)
3. Copy it and paste it anywhere to see if newlines are added on where it gets wrapped. (e.g. it becomes

```
ssssssssssssssssssssssssssssssssssssssssssss
ssssssssssssssssssssssssssssssssssssssssssss
ssssss
```

Originally vscode terminal won't add a linebreak on where it wraps, which is really convenient for a lot of bash operations, now this new behavior is not very helpful.
Repository: electron
Issue: [Bug]: Main window black screens when it's fullscreen and launches a child window
Labels: platform/macOS,bug :beetle:,status/confirmed,has-repro-gist,26-x-y,27-x-y

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a bug report that matches the one I want to file, without success.

### Electron Version

26.2.0

### What operating system are you using?

macOS

### Operating System Version

macOS Ventura 13.2.1

### What arch are you using?

arm64 (including Apple Silicon)

### Last Known Working Electron version

_No response_

### Expected Behavior

I expect that the main window stays alive when it's fullscreen and launches a child window

### Actual Behavior

child window is launched fullscreen on another Desktop/Space and main window becomes black

### Testcase Gist URL

https://gist.github.com/pushkin-/0892f7b6bf02b8b61fb3330e924e548c

### Additional Information

1. full screen main window
2. click Open Window
3. observe child window launches on another Space for some reason
4. Menu -> Close Window
5. You get sent back to the main window which is now black

Maybe related to all the other fullscreen/black screen kinds of issues I opened recently. Possibly a dupe of something
Repository: godot
Issue: Control: "Connect Signal to a Method" -> advanced -> Add Extra Call Argument drop down renders behind control view
Labels: bug,topic:editor,topic:gui

### Godot version

4.1.1.stable.official

### System information

Mac OS 13.5.2 M1 Max MBP

### Issue description

Going through the tutorial and discovered a small rendering glitch on the "Connect Signal to a Method" in the main UI. If you click advanced to add other arguments to the call back the drop down for the argument type renders behind the control obscuring the options.

![image](https://github.com/godotengine/godot/assets/1690117/cfd11768-75af-4f6e-bff2-f7145e80e992)



### Steps to reproduce

Control: "Connect Signal to a Method" -> advanced -> Add Extra Call Argument drop down renders behind control view

### Minimal reproduction project

No need. This is a minor issue with the default UI.

I hope this helps. I am enjoying this engine.
Repository: kubernetes
Issue: Test Audit policy using original (non-impersonated) user for filtering
Labels: sig/auth,help wanted,triage/accepted

(This came up in review of the https://github.com/kubernetes/enhancements/pull/4141 KEP)

We need to make sure there's a test for audit policy rules using original (non-impersonated) user for deciding whether to log the audit event or not.

The authentication filter → audit filter → impersonation filter ordering in DefaultBuildHandlerChain should make this work properly but we definitely want to test it.

We specifically want to make sure an audit policy that filters out system users (for volume reasons) will still log a request from a non-system user impersonating one of those system users.

/sig auth
/cc @enj
/help
Repository: vscode
Issue: I was asked randomly whether i wanted to use Japanese display language?
Labels: bug,l10n-platform

I just got this notification:

![Image](https://github.com/microsoft/vscode/assets/2193314/670cf9e4-b795-4705-9580-465363b0ff31)

> Would you like to change the display language for Visual Studio Code - Insiders to Japanese and start over?

My guess as to why is that settings sync synchronized the Japanese language pack from when I tested something the other day. Much like with other extension where we don't want to flood the user with notifications when syncing extensions, we should be smarter about this imo. Some ideas:

- Don't suggest to switch when the language pack was sync'd via settings sync?
- Remember preferred locale as part of global state?
- Don't suggest to switch when there is another language pack in use?
Repository: deno
Issue: deno compile fails if run in folder with package.json and uninstalled dependencies
Labels: bug,compile

```
> cat package.json
{
  "dependencies": {
    "node-fetch": "^3.3.2"
  }
}
> rm -rf node_modules
> deno compile -A npm:cowsay
> ./cowsay
error: Failed caching npm package 'node-fetch@3.3.2'.

Caused by:
    An npm specifier not found in cache: "node-fetch", --cached-only is specified.
```

I think maybe it needs to have a lockfile as well.

Maybe related: https://github.com/denoland/deno/issues/19810
Repository: tensorflow
Issue: StringLookup / tf.lookup resource cleanup on model cleared
Labels: stat:awaiting tensorflower,type:bug,comp:apis,TF 2.12

### Issue type

Bug

### Have you reproduced the bug with TensorFlow Nightly?

Yes

### Source

binary

### TensorFlow version

2.12

### Custom code

Yes

### OS platform and distribution

Linux Ubuntu 22.04

### Mobile device

_No response_

### Python version

3.10

### Bazel version

_No response_

### GCC/compiler version

_No response_

### CUDA/cuDNN version

_No response_

### GPU model and memory

_No response_

### Current behavior?

Describe the problem.

Define a simple network with a StringLookup of non-trivial size

Reload the network in a for loop.

Memory goes to infinity.

Describe the current behavior.
Memory goes up every load

Describe the expected behavior.
Memory doesn't go up every load

When using StringLookup: 

![image](https://user-images.githubusercontent.com/4107771/267815955-966e2a02-135a-4e68-a185-c49120e90092.png)

When using Hashing it works:

![image](https://github.com/tensorflow/tensorflow/assets/4107771/2145a1d1-1eaf-4595-808c-8f53a8a6616f)


### Standalone code to reproduce the issue

```shell
import time
import os

import tensorflow as tf
import psutil

def model_fn():
    X = tf.keras.Input(shape=(1,), dtype=tf.string)
    lookup = tf.keras.layers.StringLookup(
        vocabulary=tf.constant([str(x) for x in range(100_000)])
    )(X)
    Y = tf.math.reduce_sum(lookup, axis=1)

    return tf.keras.Model(inputs=[X], outputs=[Y])

model = model_fn()
model.save("/tmp/test-model")

loaded_model = None

process = psutil.Process()

def get_current_mem():
    return process.memory_info().rss / 1e6

def load():
    global loaded_model
    loaded_model = tf.saved_model.load("/tmp/test-model")

print('==========================================================')
print("starting process...")

for i in range(100_000):
    start_mem = get_current_mem()
    start = time.time()

    print(f"i={i} loading...", end='')
    load()

    curr_mem = get_current_mem()
    end = time.time()
    print(f"done (mem_usage={curr_mem - start_mem}mb took={int(end - start)}s)")
    time.sleep(0.25)
```


### Relevant log output

_No response_
Repository: go
Issue: bytes: relatively poor performance in bytes.Compare
Labels: Performance,NeedsInvestigation

### What version of Go are you using (`go version`)?
1.21

### Does this issue reproduce with the latest release?

Yes.

### What operating system and processor architecture are you using (`go env`)?

GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/Users/phil/Library/Caches/go-build'
GOENV='/Users/phil/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/phil/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/phil/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/darwin_amd64'
GOVCS=''
GOVERSION='go1.21.0'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='clang'
CXX='clang++'
CGO_ENABLED='1'
GOMOD='/dev/null'
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 x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/2w/sj4gll256rqfs6r4sgwcn3lh0000gn/T/go-build2454689691=/tmp/go-build -gno-record-gcc-switches -fno-common'

### What did you do?

For fixed length arrays (such as `github.com/google/uuid.UUID`) `bytes.Compare` perform poorly relative to a handwritten:

```
func uuidCmpByte(a, b uuid.UUID) int {
	for i := 0; i < 16; i++ {
		if d := int(a[i]) - int(b[i]); d != 0 {
			return d
		}
	}
	return 0
}
```

Bench results where there's a 
```
BenchmarkBytesCompare-8   	     262	   4459605 ns/op	       0 B/op	       0 allocs/op
BenchmarkArrayCompare-8   	     890	   1437192 ns/op	       0 B/op	       0 allocs/op
```


### What did you expect to see?

I expected the internal bytes.Compare to perform optimally.

### What did you see instead?

Probably due to the conversion a slice and the inability to unroll the loop, `bytes.Compare` performed about 3x worse.

It would be ideal to have a function that would compare fixed-length arrays optimally.

````

const sliceSize = 1000

func uuidCmpByte(a, b uuid.UUID) int {
	for i := 0; i < 16; i++ {
		if d := int(a[i]) - int(b[i]); d != 0 {
			return d
		}
	}
	return 0
}

func BenchmarkBytesCompare(b *testing.B) {
	uuids := make([]uuid.UUID, 0, sliceSize)
	for i := 0; i < sliceSize; i++ {
		uuids = append(uuids, uuid.New())
	}
	for _, uid := range uuids[:10] {
		uuids = append(uuids, uid)
	}
	b.ResetTimer()
	for n := 0; n < b.N; n++ {
		for _, a := range uuids {
			for _, b := range uuids {
				_ = bytes.Compare(a[:], b[:])
			}
		}

	}
}

func BenchmarkArrayCompare(b *testing.B) {
	uuids := make([]uuid.UUID, 0, sliceSize)
	for i := 0; i < sliceSize; i++ {
		uuids = append(uuids, uuid.New())
	}
	b.ResetTimer()
	for n := 0; n < b.N; n++ {
		for _, a := range uuids {
			for _, b := range uuids {
				_ = uuidCmpByte(a, b)
			}
		}
	}
}

````
Repository: pytorch
Issue: DISABLED test_nondeterministic_alert_histc_cuda (__main__.TestTorchDeviceTypeCUDA)
Labels: module: tests,triaged,module: flaky-tests,skipped,oncall: pt2,module: inductor

Platforms: inductor

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_nondeterministic_alert_histc_cuda&suite=TestTorchDeviceTypeCUDA) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/16792643971).

Over the past 3 hours, it has been determined flaky in 2 workflow(s) with 2 failures and 2 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT ASSUME THINGS ARE OKAY IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_nondeterministic_alert_histc_cuda`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.


Test file path: `test_torch.py`

cc @mruberry @ZainRizvi @clee2000 @ezyang @msaroufim @bdhirsh @anijain2305 @zou3519 @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @aakhundov @ColinPeppler @wconstab
Repository: flutter
Issue: `flow` unittesting should cover all possible combinations/configurations 
Labels: engine,c: proposal,P3,team-engine,triaged-engine

Otherwise we run into downstream problems where some unexpected combination of layer tree options results in an error.

This would be vastly simplified if we could simplify the complexity of the structs used for e.g. preroll/paint.

/cc @flar
Repository: flutter
Issue: Simplify `flow`
Labels: engine,P2,team-engine,triaged-engine

In particular, `PaintContext` and `PrerollContext` are both pretty complicated structs with mutually incompatible raw pointer fields (and sometimes duplicated fields).

We should do what we can to simplify this.

/cc @flar
Repository: flutter
Issue: [Impeller] Track `Entity::RenderingMode` as an `Entity` field.
Labels: engine,P2,e: impeller,team-engine,triaged-engine

... instead of assigning it as part of the FilterContents. Whether we need to render as a subpass is specific to the `Entity`.
Repository: flutter
Issue: `sysctl -n hw.optional.arm64` returns '' on some machines, causing update_dart_sdk.sh to fail
Labels: tool,P3,team-tool,triaged-tool

### Is there an existing issue for this?

- [X] I have searched the [existing issues](https://github.com/flutter/flutter/issues)
- [X] I have read the [guide to filing a bug](https://flutter.dev/docs/resources/bug-reports)

### Steps to reproduce

I don't know what machines exactly, but we've gotten a couple reports at shorebird:
https://github.com/shorebirdtech/shorebird/issues/1263
https://github.com/shorebirdtech/shorebird/issues/939

Note that these failures are not in Shorebird's code, but rather the underlying `flutter` we're depending on.

And flutter has seen at least one filed as well:
https://github.com/flutter/flutter/issues/116408

I don't know what the root cause is, but it seems the current method of determining x86 vs. arm64 on Mac fails often enough that we're seeing reports from users.

### Expected results

update_dart_sdk.sh should reliably be able to detect x86 vs. arm64 w/o failing for some users (in ways they can't fix or understand).

### Actual results

update_dart_sdk.sh fails (manifests as `flutter` failing) sometimes with:
'sysctl -n hw.optional.arm64' returned unexpected output: ''.

### Code sample

None.

### Screenshots or Video

_No response_

### Logs

_No response_

### Flutter Doctor output

The reports we've seen have been with flutters since 3.10.0 through 3.13.3.  Looking at the latest code on master, it hasn't changed:
https://github.com/flutter/flutter/blob/master/bin/internal/update_dart_sdk.sh#L67
Repository: godot
Issue: Engine hangs for half a second when selecting a node in 2D viewport or committing node rename.
Labels: bug,topic:editor,needs testing,performance

### Godot version

4.1.1.stable [bd6af8e0e]

### System information

Windows 10, Intel(R) Core(TM) i7-9750H, NVIDIA GeForce RTX 2070 Driver version 537.34 

### Issue description


https://github.com/godotengine/godot/assets/25502005/1ddebe15-17e7-48b5-a334-2afa506004d8

Selecting UI element in the 2D viewport and renaming a node in the inspector causes about a half second hang of the engine. Video recording was on a completely fresh project. All other aspects of the engine (that I have checked so far) seem to be working as expected - viewport navigation, menus, editing text to display on the button, seamless. 

Interestingly, while drag selecting, if you drag over only the button, the lag persists, if you drag over the button AND the scene in the viewport, they are instantly both selected in the hierarchy and view.

I have tried running as administrator, moving the exe and project to my ssd, external drive and internal HDD. Mobile and Fwd+ renderers tested, I have added the exe as a high priority GPU application in my display settings, I've tried running from cmd with '--disable-gpu', no errors or warnings being reported on the console version of the application.

Worth noting the NVidia driver I am running, as listed was installed today and is pretty bleeding edge.

### Steps to reproduce

Create new project, Mobile or Forward+ renderer, add 2D scene, add button, click button or drag select ONLY button.

Create new project, Mobile or Forward+ renderer, add 2D scene, rename 2D scene node in hierarchy panel.

### Minimal reproduction project

N/A