sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: Remotes UI is totally confusing
Labels: info-needed


Type: <b>Feature Request</b>

The "Remotes (Tunnels/SSH)" tab of REMOTES EXPLORER lists remotes, but shows no way to edit them. I forget how I added them originally and I can't right-click on them, and the "..." menu is useless.

VS Code version: Code 1.96.3 (91fbdddc47bc9c09064bf7acf133d22631cbf083, 2025-01-09T18:14:09.060Z)
OS version: Windows_NT x64 10.0.22631
Modes:
Remote OS version: Linux x64 5.4.0-204-generic
Remote OS version: Linux x64 5.15.167.4-microsoft-standard-WSL2
Connection to 'SSH: computelab-303-docker' could not be established  Connecting with SSH timed out


<!-- generated by issue reporter -->
Repository: kubernetes
Issue: Pop from the backoff queue whenever the active queue is empty
Labels: sig/scheduling,kind/feature,needs-triage

### What would you like to be added?

Disclaimer: this is a high level description of the idea without providing all necessary details, which can be worked on later whenever there is agreement regarding the general approach.

Whenever the active queue is empty, scheduler could pick the first pod from the backoff queue (the one with the shortest expiration time) and either schedule (assign) it right away or put it back to the unschedulable queue.

The next time the pod goes to the backoff queue it should either use it's previous backoff time if it haven't expired yet, or it should be increased as it is done currently. This way in the worst scenario, pods would have to wait their whole backoff time to get to the active queue (be rescheduled), so not degrade over the current behavior.

### Why is this needed?

The main purpose of the backoff queue is to prevent scheduler from processing unschedulable pods over and over again, which can lead to performance degradation of scheduling lower priority pods, including their starvation.

This problem is prominent because rescheduling of unschedulable pods engages time consuming preemption process, which basically depends on the overall number of lower priority pods (see https://github.com/kubernetes/kubernetes/pull/128466).

The higher max backoff time is used, the smaller performance degradation is observed. Unfortunately pods waiting in the backoff queue are "punished" for their unschedulable status by additional waiting time in case when they eventually become schedulable. This form of punishment is a side effect, but not the feature in itself, therefore this change would reduce this punishment time to the very minimum without defeating the purpose of the backoff queue.

With this feature, unschedulable pods could be rescheduled earlier shortening the punshment time to the very minimum, but without impacting scheduler performance. In effect, unschedulable pods would be expected to be rescheduled soon after some event triggered rescheduling (after passing QHints filter).

In the worst case, the backoff queue will work as currently (move pods to active on the backoff time expiration), although having this feature would allow to increase the `maxPodBackoffSeconds` from default 10s to 120s, as in practice the waiting time is expected to be very small anyway. This is important, because there are known reports that 10s backoff time still does not prevent scheduler from running into the starvation problem and the feature in itself won't address it directly, but indirectly by allowing to saftely increase the default time.
Repository: next.js
Issue: Error during dev and warning at build in middleware.ts with --turbo flag
Labels: Middleware,Runtime,Turbopack

### Link to the code that reproduces this issue

https://github.com/sommeeeer/next-middleware-edge-turbo-node

### To Reproduce

1. start the dev server with `pnpm dev`
2. open up [http://localhost:3000](http://localhost:3000) and look for the request header: `hello-from-function`.
3. close the dev server and now run it with `--turbo` flag: `pnpm devturbo`

### Current vs. Expected behavior

![Image](https://github.com/user-attachments/assets/3ae69b9a-021f-4fc5-a2ab-69027ae334ac)

So the `src/lib/node-native.ts` exports two functions. One is for the `middleware.ts` and the other one is a random async `hi()` function that dynamically imports a native Node.js API from `fs/promises`. 

Since we are not using this function in the middleware it should not be flagged. I think it should work the same way as normal `next dev` without the `--turbo` flag. 

Can note that `next build` works but with warnings. 

### Provide environment information

```bash
Operating System:
  Platform: linux
  Arch: x64
  Version: #47~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Wed Oct  2 16:16:55 UTC 2
  Available memory (MB): 14800
  Available CPU cores: 16
Binaries:
  Node: 20.18.0
  npm: 10.9.1
  Yarn: 1.22.19
  pnpm: 9.15.4
Relevant Packages:
  next: 15.1.6 // Latest available version is detected (15.1.6).
  eslint-config-next: 15.1.6
  react: 19.0.0
  react-dom: 19.0.0
  typescript: 5.7.3
Next.js Config:
  output: N/A
```

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

Turbopack, Middleware

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

next dev (local), next build (local)

### Additional context

_No response_
Repository: pytorch
Issue: torch.compiler.disable should have the option to raise an informative exception (other than `torch._dynamo.exc.Unsupported`)
Labels: triaged,oncall: pt2,module: dynamo,dynamo-logging

### 🚀 The feature, motivation and pitch

## Context

I'm working on making distributions compatible with compile. We expect that the validate step will never be compilable.
Ideally, users who run into that graph break (whether fullgraph=False and they're using TORCH_LOGS or using fullgraph=True and they look at the exception) should be guided to using `torch.distributions.Distribution.set_default_validate_args(False)` or similar to deactivate the validation step. 
That's a reasonable thing to ask users to do if we tell them the pros and cons of doing that.
Currently, the error message just says "if statements are not supported" and if we `disable()` it, we'll get even less context.

In general, if there's a way out of a graph break and we can tell people about it, we should have the tools to provide informative error messages about the macro-context.

## Feature request

An option we talked about with @bdhirsh is to have some way of customize the Unsupported error message or provide a custom error (eg, ValueError or whatever) that tells people how to avoid the graph break. 
Something like `validate = torch.compiler.disable(validate, custom_error=RuntimeError(msg))`

Before:
```
torch._dynamo.exc.UserError: Dynamic control flow is not supported at the moment.
```
After
```
RuntimeError: You are attempting to compile a distribution constructors with validate_args=True (default). To compile this without graph breaks, make sure to turn validate_args to False through the constructor or distributions.Distribution.set_default_validate_args.
```


### Alternatives

_No response_

### Additional context

_No response_

cc @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @kadeng @amjames
Repository: vscode
Issue: Still showing it as an issue even after i rectified it
Labels: info-needed


Type: <b>Bug</b>

I had an issue in my code and so it was underlined with red.
But even after i rectified it, still it is underlined but my code was running perfectly that means i fixed the issue in my code.
that red underline irritating me a lot.
Please fix it

VS Code version: Code 1.96.4 (cd4ee3b1c348a13bafd8f9ad8060705f6d4b9cba, 2025-01-16T00:16:19.038Z)
OS version: Windows_NT x64 10.0.22631
Modes:

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|AMD Ryzen 5 3500U with Radeon Vega Mobile Gfx   (8 x 2096)|
|GPU Status|2d_canvas: enabled<br>canvas_oop_rasterization: enabled_on<br>direct_rendering_display_compositor: disabled_off_ok<br>gpu_compositing: enabled<br>multiple_raster_threads: enabled_on<br>opengl: enabled_on<br>rasterization: enabled<br>raw_draw: disabled_off_ok<br>skia_graphite: disabled_off<br>video_decode: enabled<br>video_encode: enabled<br>vulkan: disabled_off<br>webgl: enabled<br>webgl2: enabled<br>webgpu: enabled<br>webnn: disabled_off|
|Load (avg)|undefined|
|Memory (System)|5.91GB (0.84GB free)|
|Process Argv|--crash-reporter-id 6f5931b0-12d5-4e47-877d-6e08ee63671d|
|Screen Reader|no|
|VM|0%|
</details><details><summary>Extensions (22)</summary>

Extension|Author (truncated)|Version
---|---|---
vscode-django|bat|1.15.0
python-environment-manager|don|1.2.7
python-extension-pack|don|1.7.0
vsc-python-indent|Kev|1.19.0
python-path|mge|0.0.14
playwright|ms-|1.1.12
debugpy|ms-|2024.14.0
python|ms-|2024.22.2
vscode-pylance|ms-|2024.12.1
playwright-snippets|nit|1.0.1
autodocstring|njp|0.6.1
java|red|1.39.0
python-extended-snippets|tus|0.0.1
intellicode-api-usage-examples|Vis|0.2.9
vscodeintellicode|Vis|1.3.2
vscode-gradle|vsc|3.16.4
vscode-java-debug|vsc|0.58.1
vscode-java-dependency|vsc|0.24.1
vscode-java-pack|vsc|0.29.0
vscode-java-test|vsc|0.43.0
vscode-maven|vsc|0.44.0
jinja|who|0.0.8


</details><details>
<summary>A/B Experiments</summary>

```
vsliv368:30146709
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythonvspyt551:31179978
vscod805cf:30301675
binariesv615:30325510
vsaa593cf:30376535
py29gd2263:31024239
vscaac:30438847
c4g48928:30535728
azure-dev_surveyone:30548225
2i9eh265:30646982
962ge761:30959799
pythonnoceb:30805159
pythonmypyd1:30879173
h48ei257:31000450
pythontbext0:30879054
cppperfnew:31000557
dsvsc020:30976470
pythonait:31006305
dsvsc021:30996838
dvdeprecation:31068756
dwnewjupyter:31046869
newcmakeconfigv2:31071590
nativerepl1:31139838
pythonrstrctxt:31112756
nativeloc2:31192216
cf971741:31144450
iacca1:31171482
notype1:31157159
5fd0e150:31155592
dwcopilot:31170013
stablechunks:31184530
6074i472:31201624
dwoutputs:31217127
hdaa2157:31222309
copilot_t_ci:31222730

```

</details>

<!-- generated by issue reporter -->
Repository: go
Issue: text/template: improve error message "incompatible types for comparison"
Labels: NeedsInvestigation,LibraryProposal

### Go version

go version go1.23.5 linux/amd64

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

```shell
GO111MODULE='on'
GOARCH='amd64'
GOBIN='/home/jdemeyer/.local/bin'
GOCACHE='/home/jdemeyer/.cache/go-build'
GOENV='/home/jdemeyer/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/jdemeyer/go/pkg/mod'
GONOPROXY='bitbucket.org/be-mobile'
GONOSUMDB='bitbucket.org/be-mobile'
GOOS='linux'
GOPATH='/home/jdemeyer/go'
GOPRIVATE='bitbucket.org/be-mobile'
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/snap/go/10818'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='local'
GOTOOLDIR='/snap/go/10818/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.23.5'
GODEBUG=''
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/jdemeyer/.config/go/telemetry'
GCCGO='gccgo'
GOAMD64='v3'
AR='ar'
CC='gcc'
CXX='g++'
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 -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build1587861785=/tmp/go-build -gno-record-gcc-switches'
```

### What did you do?

Actually, this problem came via using `helm` to template a Helm chart, but this is the essence of the problem in pure Go:
```
package main

import (
	"io"
	"text/template"
)

func main() {
	const tmpl = "{{ gt .a .b }}"
	var t = template.Must(template.New("test").Parse(tmpl))
	args := map[string]any{
		"a": 1.0,  // Intentionally incomparable types
		"b": 2,
	}
	err := t.Execute(io.Discard, args)
	if err != nil {
		panic(err)
	}
}
```

### What did you see happen?

```
panic: template: test:1:3: executing "test" at <gt .a .b>: error calling gt: incompatible types for comparison
```

### What did you expect to see?

```
panic: template: test:1:3: executing "test" at <gt .a .b>: error calling gt: incompatible types for comparison: float64, int
```

It would be helpful to add in the error message *which* types are causing the incompatibility. When using `text/template` in Helm, there are many layers in between, so the error message `incompatible types for comparison` might not be easy to debug.
Repository: vscode
Issue: KEY BOARD SHORTCUTS NOT WORKING PROPERLY
Labels: info-needed


Type: <b>Bug</b>

Some keyboard shortcuts are not working properly, especially github copilot(copilot inline chat =ctrl+I). please fix this issue or suggest me some way to correct this issue


VS Code version: Code 1.96.4 (cd4ee3b1c348a13bafd8f9ad8060705f6d4b9cba, 2025-01-16T00:16:19.038Z)
OS version: Windows_NT x64 10.0.26100
Modes:

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|Intel(R) Core(TM) i7-8665U CPU @ 1.90GHz (8 x 2112)|
|GPU Status|2d_canvas: enabled<br>canvas_oop_rasterization: enabled_on<br>direct_rendering_display_compositor: disabled_off_ok<br>gpu_compositing: enabled<br>multiple_raster_threads: enabled_on<br>opengl: enabled_on<br>rasterization: enabled<br>raw_draw: disabled_off_ok<br>skia_graphite: disabled_off<br>video_decode: enabled<br>video_encode: enabled<br>vulkan: disabled_off<br>webgl: enabled<br>webgl2: enabled<br>webgpu: enabled<br>webnn: disabled_off|
|Load (avg)|undefined|
|Memory (System)|23.78GB (13.54GB free)|
|Process Argv|C:\\Users\\hrish\\OneDrive\\Desktop\\script --crash-reporter-id d0290b4b-aeb7-43f6-b823-9cd419c9dd6e|
|Screen Reader|no|
|VM|0%|
</details><details><summary>Extensions (37)</summary>

Extension|Author (truncated)|Version
---|---|---
vscode-tailwindcss|bra|0.14.1
npm-intellisense|chr|1.4.5
path-intellisense|chr|2.10.0
es7-react-js-snippets|dsz|4.4.3
vscode-html-css|ecm|2.0.13
prettier-vscode|esb|11.0.0
auto-close-tag|for|0.5.15
auto-rename-tag|for|0.1.10
copilot|Git|1.259.0
copilot-chat|Git|0.23.2
go|gol|0.44.0
mongodb-vscode|mon|1.11.0
vscode-docker|ms-|1.29.4
debugpy|ms-|2024.14.0
python|ms-|2024.22.2
vscode-pylance|ms-|2024.12.1
remote-containers|ms-|0.394.0
remote-wsl|ms-|0.88.5
cmake-tools|ms-|1.19.52
cpptools|ms-|1.22.11
cpptools-extension-pack|ms-|1.3.0
js-atom-grammar|ms-|0.1.14
js-debug-nightly|ms-|2025.1.817
live-server|ms-|0.4.15
vscode-typescript-next|ms-|5.8.20250123
vsliveshare|ms-|1.0.5948
vscode-react-native|msj|1.13.0
oracle-java|Ora|23.0.1
LiveServer|rit|5.7.9
vscode-standard|sta|2.1.3
cmake|twx|0.0.17
intellicode-api-usage-examples|Vis|0.2.9
vscodeintellicode|Vis|1.3.2
vscode-java-debug|vsc|0.58.1
vim|vsc|1.29.0
volar|Vue|2.2.0
html-css-class-completion|Zig|1.20.0

(1 theme extensions excluded)

</details><details>
<summary>A/B Experiments</summary>

```
vsliv368:30146709
vspor879:30202332
vspor708:30202333
vspor363:30204092
vswsl492cf:30256860
vscod805cf:30301675
binariesv615:30325510
vsaa593:30376534
py29gd2263:31024239
c4g48928:30535728
azure-dev_surveyone:30548225
962ge761:30959799
pythonnoceb:30805159
pythonmypyd1:30879173
h48ei257:31000450
pythontbext0:30879054
cppperfnew:31000557
dsvsc020:30976470
pythonait:31006305
dsvsc021:30996838
dvdeprecation:31068756
dwnewjupytercf:31046870
2f103344:31071589
nativerepl2:31139839
pythonrstrctxt:31112756
nativeloc1:31192215
cf971741:31144450
iacca1:31171482
notype1:31157159
5fd0e150:31155592
dwcopilot:31170013
stablechunks:31184530
6074i472:31201624
dwoutputs:31217127
hdaa2157:31222309
copilot_t_ci:31222730

```

</details>

<!-- generated by issue reporter -->
Repository: go
Issue: crypto/internal/fips140/nistec: p256NegCond is variable time on ppc64le [1.22 backport]
Labels: Security,CherryPickCandidate

@rolandshoemaker requested issue #71383 to be considered for backport to the next 1.22 minor release.

> We'll backport this to the next minor releases.
> 
> @gopherbot please open backport issues, this is a minor security issue.
Repository: go
Issue: crypto/internal/fips140/nistec: p256NegCond is variable time on ppc64le [1.23 backport]
Labels: Security,CherryPickCandidate

@rolandshoemaker requested issue #71383 to be considered for backport to the next 1.23 minor release.

> We'll backport this to the next minor releases.
> 
> @gopherbot please open backport issues, this is a minor security issue.
Repository: TypeScript
Issue: Text between Unicode escapes within an identifier is skipped
Labels: Bug,Help Wanted

### 🔎 Search Terms

- Unicode escape sequences
- extended Unicode escapes
- variables, constants, property names, JSX identifiers, JSX attribute names…
- regular expression group names, RegExp identifiers
- bundling & transpilation

### 🕗 Version & Regression Information

- This is the behavior since #32725 lands


### ⏯ Playground Link

https://www.typescriptlang.org/play/?#code/MYewdgzgLgBAhgHQK4G8BsAmAvsZ6AsWApjALwz4YDcAUHAEbAAmRVMA9OzAKIBOvIXgC4YAYThgwIWADMAlmCYwwcALYkA5A2ZENAOhgAROUoCeIJDHUSYWvJhz3CugPx16LNpxgA5EDCJ+QRpQSFg8AHY0LDheewBOGPoAGxJySloAN1i5BlSvLj4BYTEJKVkFJRV1W2zeXJTdA2MzCysiGw1I6NiEpNSNN0yG-I4uPwCg3hogA

### 💻 Code

```ts
const a\u{62}c\u{64}e = 42;
abcde; // Error: Cannot find name 'abcde'. Did you mean 'a\u{62}c\u{64}e'?
abde; // No error
const \u{76}ar\u{69}able = 42;
variable; // Error: Cannot find name 'variable'. Did you mean '\u{76}ar\u{69}able'?
viable; // No error
```


### 🙁 Actual behavior

`abde` and `viable` are recognised but not `abcde` and `variable`.

### 🙂 Expected behavior

`abcde` and `variable` are recognised but not `abde` and `viable`.

### Additional information about the issue

Precisely, text between a <ins>4-digit or extended</ins> Unicode escape and an <ins>extended</ins> Unicode escape is ignored.
(This is not the case for text between a <ins>4-digit or extended</ins> Unicode escape and a <ins>4-digit</ins> Unicode escape.)
This happens with all kinds of identifiers, not just variable names, due to the missing line `result += text.substring(start, pos);`. This issue is opened just for trackability and is fixed in #61042.
Repository: vscode
Issue: Feature Request: Implement Extended Search Options for Git-Modified Files
Labels: feature-request,git

<!-- ⚠️⚠️ 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. -->

<!-- Describe the feature you'd like. -->
Add new scopes in the existing Search panel to specifically target files recognized by Git as modified or limit the search to the current HEAD. For instance, in the Files to include section (currently offering an “Open Editors” button), offer toggle options for (Open Editors), (Git: modified), and (Git: current head). This makes it simpler to locate and remove debugging code or other changes by focusing on the most relevant files only.
Repository: deno
Issue: Unexpected SyntaxError while compiling `await (() => 42)`
Labels: repl

Version: Deno 2.1.7

```
> () => 42
[Function (anonymous)]
> await (() => 42)
Uncaught SyntaxError: Malformed arrow function parameter list
> await [() => 42]
[ [Function (anonymous)] ]
> const f = () => 42; await f
[Function: f]
> await function() { return 42 }
[Function (anonymous)]
```

`await (() => 42)` should be treated as a valid syntax.
Repository: vscode
Issue: request fail
Labels: info-needed


Type: <b>Bug</b>

I am getting 
```Sorry, your request failed. Please try again```
many times


VS Code version: Code 1.96.4 (cd4ee3b1c348a13bafd8f9ad8060705f6d4b9cba, 2025-01-16T00:16:19.038Z)
OS version: Windows_NT x64 10.0.26100
Modes:

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz (8 x 2419)|
|GPU Status|2d_canvas: enabled<br>canvas_oop_rasterization: enabled_on<br>direct_rendering_display_compositor: disabled_off_ok<br>gpu_compositing: enabled<br>multiple_raster_threads: enabled_on<br>opengl: enabled_on<br>rasterization: enabled<br>raw_draw: disabled_off_ok<br>skia_graphite: disabled_off<br>video_decode: enabled<br>video_encode: enabled<br>vulkan: disabled_off<br>webgl: enabled<br>webgl2: enabled<br>webgpu: enabled<br>webnn: disabled_off|
|Load (avg)|undefined|
|Memory (System)|15.75GB (7.36GB free)|
|Process Argv|--crash-reporter-id 79bb009f-2083-4c99-8f47-5b9ed7aad7d0|
|Screen Reader|no|
|VM|0%|
</details><details><summary>Extensions (24)</summary>

Extension|Author (truncated)|Version
---|---|---
code-runner|for|0.12.2
copilot|Git|1.259.0
copilot-chat|Git|0.23.2
data-workspace-vscode|ms-|0.5.0
mssql|ms-|1.27.0
sql-bindings-vscode|ms-|0.4.0
sql-database-projects-vscode|ms-|1.4.5
debugpy|ms-|2024.14.0
python|ms-|2024.22.2
jupyter|ms-|2024.11.0
jupyter-keymap|ms-|1.1.2
jupyter-renderers|ms-|1.0.21
vscode-jupyter-cell-tags|ms-|0.1.9
vscode-jupyter-slideshow|ms-|0.1.6
remote-containers|ms-|0.394.0
remote-ssh|ms-|0.116.1
remote-ssh-edit|ms-|0.87.0
remote-wsl|ms-|0.88.5
vscode-remote-extensionpack|ms-|0.26.0
remote-explorer|ms-|0.4.3
remote-server|ms-|1.5.2
windows-ai-studio|ms-|0.8.4
vscode-yaml|red|1.15.0
r|REd|2.8.4

(2 theme extensions excluded)

</details><details>
<summary>A/B Experiments</summary>

```
vsliv368:30146709
vspor879:30202332
vspor708:30202333
vspor363:30204092
vscod805:30301674
binariesv615:30325510
vsaa593cf:30376535
py29gd2263:31024239
c4g48928:30535728
azure-dev_surveyone:30548225
962ge761:30959799
pythonnoceb:30805159
pythonmypyd1:30879173
h48ei257:31000450
pythontbext0:30879054
cppperfnew:31000557
dsvsc020:30976470
pythonait:31006305
dsvsc021:30996838
dvdeprecation:31068756
dwnewjupytercf:31046870
nativerepl2:31139839
pythonrstrctxt:31112756
nativeloc2:31192216
cf971741:31144450
iacca1:31171482
notype1:31157159
5fd0e150:31155592
dwcopilot:31170013
stablechunks:31184530
6074i472:31201624
dwoutputs:31217127
9064b325:31222308
copilot_t_ci:31222730

```

</details>

<!-- generated by issue reporter -->
Repository: godot
Issue: Imeadiate usage of a duplicated `ViewportTexture` result in null acess, despite being instanciated.
Labels: needs testing,topic:gui

### Tested versions

4.3.stable

### System information

linux

### Issue description

This may ocour to any node, and is not tested, as it apeared in this context.

But, when .duplicating a ViewportTexture, one cant acess it imediately.

Despite it showing a reference id:

REF1	<ViewportTexture#-9223372012745915145>
VAR1	2987
REF2	<ViewportTexture#-9223372012309707516> 

the error:
"
Attempt to call 'save_png_to_buffer' in base 'null instance' on a null instance
"
is trhown, but there is already the reference "9223372012309707516" being confirmed as instanciated in memory already.

So, what?



### Steps to reproduce

This code:
```

extends Node

func _ready() -> void:
	var aa = get_viewport().get_texture()
	printt("REF1",aa)
	printt("VAR1",aa.get_image().save_png_to_buffer().size())
	var bb = aa.duplicate()
	printt("REF2",bb)
	printt("VAR2",bb.get_image().save_png_to_buffer().size())

```

### Minimal reproduction project (MRP)

[Duplicate Bug.zip](https://github.com/user-attachments/files/18538682/Duplicate.Bug.zip)