sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: node
Issue: HTTP Server close is taking up to 5 seconds in node 18
Labels: http

### Version

v18.18.2

### Platform

Darwin MacBook-Pro-de-Daniel.local 23.0.0 Darwin Kernel Version 23.0.0: Fri Sep 15 14:43:05 PDT 2023; root:xnu-10002.1.13~1/RELEASE_ARM64_T6020 arm64

### Subsystem

http

### What steps will reproduce the bug?

1. Create an http server
2. Start listening
3. Take at least one request
4. Try to close the server
5. It takes exactly 5 seconds

### How often does it reproduce? Is there a required condition?

I have only reproduced the bug in node 18, but is deterministic, it happens every time

### What is the expected behavior? Why is that the expected behavior?

In node 19 and 20 it's only taking 0.5 seconds. Thats a normal time that I would expect.

### What do you see instead?

I see 5 seconds of delay in order to close

### Additional information

I've reproduced the error in this repository with a bare minimum with Github Actions: [DanielRamosAcosta/nodejs-close-server-bug](https://github.com/DanielRamosAcosta/nodejs-close-server-bug)

Here is the CI report:
* Node 18: [server close: 4.990s](https://github.com/DanielRamosAcosta/nodejs-close-server-bug/actions/runs/6520497291/job/17708103919#step:4:5)
* Node 19: [server close: 0.652ms](https://github.com/DanielRamosAcosta/nodejs-close-server-bug/actions/runs/6520497291/job/17708103986#step:4:5)
* Node 20: [server close: 0.59ms](https://github.com/DanielRamosAcosta/nodejs-close-server-bug/actions/runs/6520497291/job/17708104045#step:4:5)

This is affecting to [a library](https://github.com/DanielRamosAcosta/tepper) I'm maintaining similar to supertest. If you see the CI there, Node 18 tests are taking very long due to the servers being closed.
Repository: next.js
Issue: Data requests with `X-Nextjs-Data: 1` header when middleware is present return 200 on 404
Labels: bug,Pages Router

### Link to the code that reproduces this issue

https://github.com/huumn/repro-nextjs-data-404-resp-200

### To Reproduce

1. start application (it's the repro template with the example middleware - any middleware will trigger the bug)
2. open browser console
3. run the following
```js
const headers = new Headers()
headers.append('X-Nextjs-data', 1)
fetch('http://localhost:3000/_next/data/this_doesnt_exist.json', { headers }).then(console.log)
```
4. note the response code and empty object body

This is recreating fetching serverside props on client navigation.

Any `/_next/data/` path exhibits this behavior but this is a practical problem as these paths change on deployment, ie `/_next/data/:deployment_id/:path*`. If the middleware.js file is removed, the application 404s as expected.

### Current vs. Expected behavior

Current: returns 200 and an empty json object in body so client thinks route is good and the data is just empty
Expected: returns 404 so client can refresh routes

### 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: arm64
  Version: Darwin Kernel Version 22.5.0: Thu Jun  8 22:22:20 PDT 2023; root:xnu-8796.121.3~7/RELEASE_ARM64_T6000
Binaries:
  Node: 18.17.0
  npm: 9.6.7
  Yarn: 1.22.10
  pnpm: N/A
Relevant Packages:
  next: 13.5.5-canary.15
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.1.3
Next.js Config:
  output: N/A
```


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

Data fetching (gS(S)P, getInitialProps)

### Additional context

Anytime we deploy in prod, our customers using pwas or those actively online get served stale data when navigating until they hard close or refresh respectively.

I believe the 404 is getting rewritten to 200 here: https://github.com/vercel/next.js/blob/c6fe20a31ff4f62ee75c08cd0eae9ceaba7ec50d/packages/next/src/server/lib/router-server.ts#L205-L215
Repository: godot
Issue: _update_node_path lacks sufficent context to properly rename paths upon node renames, resulting in errors.
Labels: bug,topic:editor,usability

### Godot version

a574c0296b38d5f786f249b12e6251e562c528cc

### System information

Windows 11

### Issue description

When a node is renamed in the scene, the function perform_node_renames is called. This loops through the tree and then digs down deep into the properties in order to find any node paths relevant to the node which was just renamed, and update accordingly. However, there are common instances where it can't do this. Since it only considers the path relevant to the base node, there will be instances where it considers a path to be broken. However, there are plenty of nodes such as AnimationMixer nodes which have an explicit root node and then considers all paths in the animations relative to that.

It also does not adequately reject attempts to rename default paths in editable subscenes or foreign resources, which would always otherwise be disallowed.

### Steps to reproduce

For this specific bug, simply open the sub_model.tscn in the MRP and attempt to rename the node called 'target' to anything.

### Minimal reproduction project

[unique_names_testbed.zip](https://github.com/godotengine/godot/files/12908328/unique_names_testbed.zip)
Repository: godot
Issue: Missing extents conversion causes "extents not declared in the current scope" error on coverted scripts
Labels: bug,topic:gdscript,needs testing

### Godot version

4.2.dev [51cc34a99fea7fbccf8387c51c03fb39a9b7b290]

### System information

Ubuntu 22.04.3 LTS

### Issue description

This issue is a side effect of #82754, that fixes #77931.


As explained in this [comment](https://github.com/godotengine/godot/issues/77931#issuecomment-1741884592), Godot 4.x doesn't recognize the `extents` property after the conversion of a Godot 3.x script, rising the error `Identifier 'extents' not declared in the current scope`. 

This is expected since the property doesn't exist anymore in Godot 4.x, however this behaviour does not satisfy backward compatibility nor convert the atributte.

Disclaimer: The atribbute works fine when used as `self.extents` (maybe because it forces the use of getters/setters? idk)

A solution would be related to this [comment](https://github.com/godotengine/godot-proposals/issues/7420#issuecomment-1658828366).


### Steps to reproduce

- Create a Godot 3.x project with a simple scene and add ReflectionProbe node (works with other nodes that use `extents`).

- Add a script to it, trying to access the `extents` property directly such as `extents = Vector3(2,2,2)`

- Convert the projet to Godot 4.x

- Try running the project


### Minimal reproduction project

N/A
Repository: rust
Issue: Associated type bound with lifetime failure
Labels: A-diagnostics,A-lifetimes,A-associated-items,T-compiler,C-bug,T-types

I tried this code:

```rust
// does not work

pub trait P { // -> P<'x>
    type P: std::ops::Mul;
}

impl<'x, X: S + 'x, U: A<'x, X = X>> P for U { // -> P<'x>
    type P = X::S;
}

pub trait A<'x> {
    type X: 'x;
}

// works

pub trait Q {
    type Q: std::ops::Mul;
}

impl<X: S, U: B<X = X>> Q for U {
    type Q = X::S;
}

pub trait B {
    type X: S;
}

// sort of works

pub trait R {
    type R: std::ops::Mul;
}

impl<X: S, U: for<'x> C<X<'x> = X>> R for U {
    type R = X::S;
}

pub trait C {
    type X<'x>: S + 'x;
}

pub trait S {
    type S: std::ops::Mul;
}
```

I expected to see these all either work or give an appropriate diagnostic message.

Instead, in the first case, the error given is that `X` is unconstrained, which it is not according to https://rust-lang.github.io/rfcs/0447-no-unused-impl-parameters.html. The real (unreported) issue it seems to have is that `'x` is unconstrained, which is more understandable, but then in this case there doesn't seem to be a way to handle this case of type bounds with GATs. 

The other 2 compile as expected. The last case attempts to abstract away the lifetime from the trait using a GAT and a HRTB, but in that case `X` doesn't quite seem to be bound as one might hope. When I actually try to use it, I get a `lifetime mismatch`.

### Meta

```
$ rustc +nightly --version --verbose
rustc 1.75.0-nightly (187b8131d 2023-10-03)
binary: rustc
commit-hash: 187b8131d4f760f856b214fce34534903276f2ef
commit-date: 2023-10-03
host: x86_64-apple-darwin
release: 1.75.0-nightly
LLVM version: 17.0.2

$ rustc +stable --version --verbose
rustc 1.72.1 (d5c2e9c34 2023-09-13)
binary: rustc
commit-hash: d5c2e9c342b358556da91d61ed4133f6f50fc0c3
commit-date: 2023-09-13
host: x86_64-apple-darwin
release: 1.72.1
LLVM version: 16.0.5
```

### Compiler Output

```
error[E0207]: the type parameter `X` is not constrained by the impl trait, self type, or predicates
 --> assoc-bounds.rs:7:10
  |
7 | impl<'x, X: S + 'x, U: A<'x, X = X>> P for U { // -> P<'x>
  |          ^ unconstrained type parameter

error: aborting due to previous error

For more information about this error, try `rustc --explain E0207`.
```
Repository: godot
Issue: Only a single SubViewport with `use_xr` enabled will render.
Labels: enhancement,topic:xr

### Godot version

4.1.2 Official

### System information

Win11, Vulkan

### Issue description

When using SubViewports that have `use_xr` enabled, only a single SubViewport will render.

### Steps to reproduce

add multiple subviewports to the scene, enable `use_xr`, and note that only a single subviewport is rendered at a time.

### Minimal reproduction project

You will need to toggle visibility on either canvas layer, and run the project again for it to update.

[minimal.zip](https://github.com/godotengine/godot/files/12908892/minimal.zip)
Repository: rust
Issue: rust-installer may soon be too VM resource hungry for some 32-bit native builds
Labels: O-netbsd,T-release

Hi,

while watching the build of rust 1.73.0 on the various NetBSD targets we support via our packaging system `pkgsrc`, some of those targets slower than others, it appears to me that somewhat surprisingly, the `rust-installer` program is perhaps the most resource hungry in terms of virtual memory of all the processes used to complete a build and installation.  On amd64, I've seen it balloon to 1.8GB, and on 32-bit armv7, I've observed it ballooning to 1.5GB.  I predict that unless something is done to reign in and/or optimize the virtual memory consumption of `rust-installer`, it is going to be the first process which causes `rust` to no longer to be possible to build (and install) natively on various 32-bit platforms.  If I'm not terribly mistaken, e.g. NetBSD's armv7 port(s) have an upper bound on user-mode virtual memory when executed on 32-bit hardware of somewhere in the area around 1.8GB.

I'll admit that I have not (yet) looked closely at what it is that `rust-installer` does which causes it to behave in this manner, or the particular way it goes about doing this, and therefore have no concrete suggestion for what needs to be improved / optimized or done differently.

Input solicited on whether this is easy, difficult or near-impossible to do anything about this issue.
Repository: rust
Issue: Spurious tests/ui/panics/default-backtrace-ice.rs failures
Labels: T-compiler,C-bug,A-CI,A-panic,A-backtrace,I-flaky-test

```
---- [ui] tests/ui/panics/default-backtrace-ice.rs stdout ----
diff of stderr:

7 
8 aborting due to `-Z treat-err-as-bug=1`
- (end_short_backtrace)
11 (begin_short_backtrace)
12 (end_short_backtrace)
13 (begin_short_backtrace)
---
```

The error has been seen on x86_64-apple-2 and on i686-mingw so far.

The test was last touched in #111052, cc @nnethercote 

https://github.com/rust-lang/rust/pull/114465#issuecomment-1665919855
https://github.com/rust-lang/rust/pull/115645#issuecomment-1710638960
https://github.com/rust-lang/rust/pull/116548#issuecomment-1754072458
https://github.com/rust-lang/rust/pull/115927#issuecomment-1723260809
https://github.com/rust-lang/rust/pull/116530#issuecomment-1752660181
https://github.com/rust-lang/rust/pull/116527#issuecomment-1752347408
https://github.com/rust-lang/rust/pull/109882#issuecomment-1752572158
https://github.com/rust-lang/rust/pull/116915#issuecomment-1837719134
Repository: yt-dlp
Issue: Support for /@live "the official Youtube playlist"
Labels: site-enhancement,triage

### DO NOT REMOVE OR SKIP THE ISSUE TEMPLATE

- [X] I understand that I will be **blocked** if I *intentionally* remove or skip any mandatory\* field

### Checklist

- [X] I'm requesting a feature unrelated to a specific site
- [X] I've looked through the [README](https://github.com/yt-dlp/yt-dlp#readme)
- [X] I've verified that I'm running yt-dlp version **2023.10.13** ([update instructions](https://github.com/yt-dlp/yt-dlp#update)) or later (specify commit)
- [X] I've searched [known issues](https://github.com/yt-dlp/yt-dlp/issues/3766) and the [bugtracker](https://github.com/yt-dlp/yt-dlp/issues?q=) for similar issues **including closed ones**. DO NOT post duplicates
- [X] I've read the [guidelines for opening an issue](https://github.com/yt-dlp/yt-dlp/blob/master/CONTRIBUTING.md#opening-an-issue)

### Provide a description that is worded well enough to be understood

https://www.youtube.com/@live is not working now.

command:
`yt-dlp --print "%(id)s;%(channel_id)s;%(uploader_id)s;%(title)s" https://www.youtube.com/@live -vU`



### Provide verbose output that clearly demonstrates the problem

- [X] Run **your** yt-dlp command with **-vU** flag added (`yt-dlp -vU <your command line>`)
- [ ] If using API, add `'verbose': True` to `YoutubeDL` params instead
- [X] Copy the WHOLE output (starting with `[debug] Command-line config`) and insert it below

### Complete Verbose Output

```shell
[debug] Command-line config: ['--print', '%(id)s;%(channel_id)s;%(uploader_id)s;%(title)s', 'https://www.youtube.com/@live', '-vU']
[debug] Encodings: locale cp1252, fs utf-8, pref cp1252, out utf-8, error utf-8, screen utf-8
[debug] yt-dlp version stable@2023.10.13 [b634ba742] (pip)
[debug] Python 3.11.5 (CPython AMD64 64bit) - Windows-10-10.0.22621-SP0 (OpenSSL 3.0.9 30 May 2023)
[debug] exe versions: ffmpeg 5.1.2-essentials_build-www.gyan.dev (setts), ffprobe 5.1.2-essentials_build-www.gyan.dev
[debug] Optional libraries: Cryptodome-3.19.0, brotli-1.1.0, certifi-2023.07.22, mutagen-1.47.0, sqlite3-3.42.0, websockets-10.4
[debug] Proxy map: {}
[debug] Loaded 1890 extractors
[debug] Fetching release info: https://api.github.com/repos/yt-dlp/yt-dlp/releases/latest
Available version: stable@2023.10.13, Current version: stable@2023.10.13
yt-dlp is up to date (stable@2023.10.13)
[youtube:tab] Extracting URL: https://www.youtube.com/@live
[youtube:tab] @live: Downloading webpage
[debug] [youtube:tab] Selected tab: 'UC4R8DWoMoI7CAwX8_LjQHig' (), Requested tab: ''
[download] Downloading playlist: @live
[youtube:tab] Playlist @live: Downloading 0 items
[download] Finished downloading playlist: @live
```
Repository: godot
Issue: Label Node Inspector: Resetting Visible Characters control sets wrong default on Visible Ratio control
Labels: bug,topic:gui

### Godot version

4.2.beta

### System information

Windows 11

### Issue description

Label has two controls, Visible Ratio (normalized 0..1 to show the given portion of the label's characters) and Visible Characters (integer count of characters shown, -1 means all)

The two controls are linked. (changing one changes the other)

When resetting the Visible Ratio to its default (1.0) by clicking the icon, Visible Characters is also reset to its default (-1).

When resetting Visible Characters to its default (-1), Visible Ratio is erroneously set to 0, which results in the inspector (and possibly the control) to be in an invalid state.

### Steps to reproduce

1. Create a Label, add some text.

2. Slide the Visible Ratio control to about 0.5
3. Observe: Visible Characters changes to a rounded fraction of the visible chars.
4. Click the "Reset" cirular arrow next to the Visible Ratio control.
5. Observe: Visible Characters is reset to -1 ✅
6. Repeat Step 2.
7. Click the "Reset" circular arrow next to the **Visible Characters** control.
8. Observe: The text fully shows again
9. Observe: Visible Ratio slider is erroneously set to 0 (should be set to its default, 1.0) ❌

![godot windows editor x86_64_zQ4pqeVKi4](https://github.com/godotengine/godot/assets/8904620/5dd4998e-ec5a-41a1-a5e9-16353725572f)


10. Save project, close godot, reopen project
11. Observe: The Label is now invisible ❌, because what was serialized was the wrong ratio override. The dependent Visible Characters control was changed (even though user intent was the exact opposite - to have it reset to -1, and thus Visible Ratio to 1.0, not 0.0)

### Minimal reproduction project

Please note that since this project is "saved" and godot was closed, it will already be in state step 11 with the 3rd label being fully invisible. The screenshot above shows the label before saving & closing.

[label-bug-repro.zip](https://github.com/godotengine/godot/files/12909551/label-bug-repro.zip)
Repository: godot
Issue: adding items to simple inventory with C# script generate stack error on godotsharp_internal_refcounted_disposed()
Labels: needs testing,topic:dotnet

### Godot version

v4.1.2.rc1.mono.official [58f0cae4a]

### System information

Windows 10 Pro, NVIDIA GeForce GTX 950 

### Issue description

Error for adding items into a simple inventory with a button using C#: 


### Steps to reproduce

I created a simple inventory, I used Area 2D ... and GridContainer, and it worked fine, but after some added with the button I got this error:
```
E 0:00:08:0515   Godot.NativeInterop.NativeFuncs.generated.cs:101 @ void Godot.NativeInterop.NativeFuncs.godotsharp_internal_refcounted_disposed(IntPtr , IntPtr , Godot.NativeInterop.godot_bool ): FATAL: Condition "!Object::cast_to<RefCounted>(p_ptr)" is true.
  <C++ Source>   modules/mono/glue/runtime_interop.cpp:165 @ godotsharp_internal_refcounted_disposed()
  <Stack Trace>  Godot.NativeInterop.NativeFuncs.generated.cs:101 @ void Godot.NativeInterop.NativeFuncs.godotsharp_internal_refcounted_disposed(IntPtr , IntPtr , Godot.NativeInterop.godot_bool )
                 GodotObject.base.cs:117 @ void Godot.GodotObject.Dispose(Boolean )
                 GodotObject.base.cs:80 @ void Godot.GodotObject.Finalize()
```
I cannot figure to fix it and I think there is a bug.
I added a Godot project to see this error.
[Inventory3D_001.zip](https://github.com/godotengine/godot/files/12909623/Inventory3D_001.zip)


### Minimal reproduction project

I added a Godot project to see this error.
[Inventory3D_001.zip](https://github.com/godotengine/godot/files/12909623/Inventory3D_001.zip)
Repository: godot
Issue: Class Name is lost when creating new one by duplicating existing script
Labels: discussion,topic:gdscript,topic:editor

### Godot version

4.1.2

### System information

Win 10

### Issue description

After creating new script by duplicating script with already made custom class_name, that class_name is lost inside godot.

### Steps to reproduce

Exists a script with any custom created resource class_name
for example we have this script
```
extends Resource
class_name NewResource
```
After creating this script we now can use NewResrource as resource, it's registered inside Godot.
Now if we want to create another class_name by duplicating existing one, new script will have same header with
```
extends Resource
class_name NewResource
```
and even if we rename `class_name` to something else in new script, class_name from original script is lost inside godot.
To register back old class_name we should go back into that script, make some changes to class_name name and save the script again.

### Minimal reproduction project

"N/A"
Repository: rust
Issue: Const validation error messages have lots of duplication
Labels: T-compiler,A-translation

In the porting to translatable diagnostics, the error messages from const validation where set up in a way that causes tons of code and text duplication: 

https://github.com/rust-lang/rust/blob/985795270e35998d08d5069b45cde0a9c3dfc54b/compiler/rustc_const_eval/src/errors.rs#L613-L624

https://github.com/rust-lang/rust/blob/985795270e35998d08d5069b45cde0a9c3dfc54b/compiler/rustc_const_eval/messages.ftl#L409-L414

We shouldn't have one variant per pointer kind here, we should just tell the diagnostic about the pointer kind so that all the other text does only have to be written once. For those "dangling" messages we also should just have a single template, that only splits cases for the tail (explaining why this particular pointer is dangling). Currently we get a huge combinatorial explosion of all the things that appear in these messages, making maintenance of this code a pain.

I was about to introduce the information of whether the reference is shared or mutable, but the current system makes that way too complicated, so I'll hold off on that for now.

Cc @fee1-dead @davidtwco
Repository: terminal
Issue: Quake mode full screen doesn't reopen with full heightwhen closing and resummoning
Labels: Issue-Bug,Product-Terminal,Area-Windowing

### Windows Terminal version

 1.18.2681.0

### Windows build number

10.0.22621.0

### Other Software

_No response_

### Steps to reproduce

On a multi-monitor setup (primary monitor center: 2560x1400, other monitor left: 1920x1080). Does not happen with only one display (tested on Surface Pro 9)

1. Summon quake mode window with the shortcut (bound to F10 on my machine)
    ![image](https://github.com/microsoft/terminal/assets/16977204/c6b5e6fb-5082-420d-b27f-7af4087a8244)
2. Change to full screen with F11 
    ![image](https://github.com/microsoft/terminal/assets/16977204/e51e88ca-b379-4e08-b74d-30749fb8820b)
3. Hide the quake mode window again
4. Resummon the window
    ![image](https://github.com/microsoft/terminal/assets/16977204/abc5b6b3-07d7-4f08-ba69-3383ba1a36c5)

### Expected Behavior

Quake mode window reappears again in full screen mode, covering my screen in its entirety.

### Actual Behavior

Quake mode window reappears covering around half of the montor. Pressing F11 once restores the normal quake window view, pressing it again puts in to full screen properly again.