sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Light values incorrect when scene imported from Blender
Labels: bug,confirmed,topic:import,topic:3d

### Tested versions

v4.2.2.stable.mono.official [15073afe3]

### System information

Godot v4.2.2.stable.mono - Windows 10.0.22631 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1050 Ti (NVIDIA; 31.0.15.5222) - AMD Ryzen 5 3600 6-Core Processor (12 Threads)

### Issue description

Using .blend files during development, the light values imported is vastly higher than it is in Blender. Provided Godot project with included blend file. The only light from the blend scene not available is the Area light.

Light value comparison:
Point light : 10w in blender, 543.514 in Godot
Spot light: 10w in blender, 543.514 in Godot
Sun light: 1.0 strength in blender, 683 in Godot

### Steps to reproduce

Open Blender, create lights, save blend file and open up in Godot.

### Minimal reproduction project (MRP)

[BlenderLightIssue.zip](https://github.com/godotengine/godot/files/15379912/BlenderLightIssue.zip)
Repository: node
Issue: Support load balancing HTTP requests across worker threads
Labels: feature request,worker

I think we can support load balancing HTTP requests across worker threads by leveraging the same mechanisms that allows Cluster to do it. If a libuv handle can cross processes, it definitely can cross threads.

I've tried to do it _outside_ of core in https://github.com/mcollina/tbal, but unfortunately it does not work because it requires some mangling of libuv handles that is only possible from within core.

The idea is to allow worker threads to have an libuv IPC channel similar to child processes, so that they can exchange libuv handles through it.

This should be opt-in.
Repository: godot
Issue: Label's shadow outline overlaps when transparent
Labels: discussion,documentation,topic:gui

### Tested versions

Reproducible in 4.2.stable

### System information

v4.2.stable

### Issue description

![Capture](https://github.com/godotengine/godot/assets/157412753/4156044a-7186-4086-b762-bc2d00c9aba9)
The Label has a `font_shadow_color` set to a color with some transparency, and a `shadow_outline_size` set. The expected behavior is that the entire shadow, including the outline, would have the color set in font_shadow_color. However, you can see that the shadow outline visibly has a different alpha value than the shadow itself.

### Steps to reproduce

Create a Label node. Set `font_shadow_color` to any color with alpha <1. Set `shadow_outline_size` to some value >0.

### Minimal reproduction project (MRP)

N/A
Repository: TypeScript
Issue: FEATURE REQUEST: For TypeScript / JS add new refactor feature: if class method can be static add tooltip "make method static"
Labels: Suggestion,Awaiting More Feedback,Domain: Refactorings

<!-- ⚠️⚠️ 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. -->

### TypeScript new refactor feature

If class method can be static (doesnt use `this` in code body) - add tooltip menu `make method static` with refactor all usages to call this method with static call (`Class.Method`)
Repository: stable-diffusion-webui
Issue: [Feature Request]: SRFormer Support
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 ?

Enable the use of SRFormer models like 1xDeJPG_SRFormer_light

### Proposed workflow

1. Go to extras tab
2. Select an SRFormer model
3. Enjoy


### Additional information

_No response_
Repository: TypeScript
Issue: Incorrect type handing/reduction
Labels: Needs More Info

### 🔎 Search Terms

withTranslation, reduxForm, IntrinsicAttributes

### 🕗 Version & Regression Information

- This is the behavior in every version I tried (that supports this type checking), and I reviewed the FAQ for entries about

### ⏯ Playground Link

https://www.typescriptlang.org/play/?#code/JYWwDg9gTgLgBAJQKYEMDG8BmUIjgcilQ3wG4AoUSWOAbziIBMBXADwDFoQAaOASQB2AKyQYkjTlBAAFHGADOcAL5xsuAkzYBaTFzKVw0ePQDuwGAAsAKlBQD5AGxQxgEAbwDq567ftOXbsqqOHiExDBawACMABwCSKww+uQwAJ5gSHBWshAKcAC8dHBgAFxwAswgAEZIUMoUaRlZkiDswEgOjIqF9ADWAPxlFdW19SnpmVYAgg4OOXmF2XKKAGRwXpY2do7OrgINE1lWBVkzc8twa4IiYhJc8-IAPFYtbR1dvNOzDwB8FORoNzyeAAcROAAppGUrFYAJQFH5wR6gADmcBQDhg+VoAGUYFBgAIUZCAHRgWEqAD0fwBQNBLXEJ00HC4z1e7U68k+Z1+4PouikZXwmHwylh4JBsIogPs9K4JzMm18OwCAnB4pBDMYUvI5AS1HgMuBcHYEPh+URj018rA2KiVL+QA

### 💻 Code

```ts
import React from 'react';
import { reduxForm, InjectedFormProps } from 'redux-form';
import { withTranslation, WithTranslation } from 'react-i18next';

type TProps = { p: number };
type TFormFields = { k?: number };
type TAllProps = TProps & WithTranslation;
type TT = TAllProps & InjectedFormProps<TFormFields, TAllProps>;

const G = (P: TT) => <img alt={String(P.p)} />;
const GFormed = reduxForm<TFormFields, TAllProps>({ form: 'f' })(G);
const GForm = withTranslation()(GFormed);

export const F = () => <GForm p={1} />;
```


### 🙁 Actual behavior

It complains about the last line, about `p={1}` -
> `Type '{ p: number; }' is not assignable to type 'IntrinsicAttributes & Omit<Subtract<DecoratedFormProps<TFormFields, TAllProps, string> | undefined, WithTranslationProps>, keyof WithTranslation<...>> & WithTranslationProps'.`
>  `Property 'p' does not exist on type 'IntrinsicAttributes & Omit<Subtract<DecoratedFormProps<TFormFields, TAllProps, string> | undefined, WithTranslationProps>, keyof WithTranslation<...>> & WithTranslationProps'.`

It is wrong or non-sensical, as all of those types I used add or omit their high-order-component types from the type I pass, so `ComponentType<TProps>` should end up being the type of `GForm`, but it is not

### 🙂 Expected behavior

No type errors

### Additional information about the issue

_No response_
Repository: vscode
Issue: Confusion with input tag in basicMarkupHtmlTags
Labels: bug,debt,markdown

This list says `List of safe, non-input html tags.`, but then 'input' was added to it, and I'm not sure whether that is a problem.

https://github.com/microsoft/vscode/blob/e5dfe045dbed2ebd6e7427e53e40a9f935b50318/src/vs/base/browser/dom.ts#L1863
Repository: flutter
Issue: [Impeller] automatic resource layout tracking for Vulkan
Labels: P2,e: impeller,team-engine,triaged-engine

Currently layout state for Vulkan resources (mostly just images) is pretty hardwired, this leads to some edge cases where we need a hole punch to make things fast: https://github.com/flutter/engine/pull/52908

Could we do better here? Yes, but it would be some work. The approximate solution for us is likely to follow the outline in https://www.youtube.com/watch?v=d15RXWp1Rqo .

TLDR:

Track resource states _per_ command buffer and _per_ queue. Automatically insert barriers during queue submission if resource state doesn't match expected state of cmd buffer. Assume first usage in a cmd buffer is the correct state. 

Unlike previous attempts, we do not track layout state globally per resource. We may need to output additional cmd buffers when submitting in order to transition resources to the correct state. This would be wasteful for common cases such as render passes, so maybe we explore a system where we always delay submitting the previously submitted cmd buffer so we can use it to hold layout transitions for the next cmd buffer.

This would also be a requirement to make flutter GPU feasible on Vulkan.
Repository: go
Issue: net/http/httputil: RoundTripper leaving side effect status code 1XX in responseWriter
Labels: NeedsInvestigation

### Go version

go1.22.3 darwin/arm64

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

```shell
GO111MODULE='on'
GOARCH='arm64'
GOBIN=''
GOCACHE='/Users/gopher/Library/Caches/go-build'
GOENV='/Users/gopher/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/gopher/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/gopher/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/Users/gopher/sdk/go1.22.3'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/Users/gopher/sdk/go1.22.3/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.22.3'
GCCGO='gccgo'
AR='ar'
CC='clang'
CXX='clang++'
CGO_ENABLED='1'
GOMOD='/Users/gopher/workspace/dags/projects/dagshub/gogs/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/pp/1mc266xs6x57phbmgzl5js2w0000gn/T/go-build60180279=/tmp/go-build -gno-record-gcc-switches -fno-common'
```


### What did you do?

I upgraded go from 1.22.1 to 1.22.3, and part of my http proxy response modifier stopped working correctly.


### What did you see happen?

I setup my ReverseProxy like so:
```go
proxy := &httputil.ReverseProxy{
	Director:       ctx.Redirect,
	Transport:      ctx,
	ModifyResponse: ctx.MyModifyResponse,
	ErrorHandler:   stubErrorHandler,
}

proxy.ServeHTTP(ctx.Resp, ctx.Req.Request)
```
In my function `ctx.MyModifyResponse` I check the status code of my `http.ResponseWriter` to verify nothing was written previously.

```go
if ctx.Resp.status != 0 {
    return errors.WithStack(&ContextWrittenError{})
}
```

But now since https://github.com/golang/go/commit/972870da11bb4ddd3df393473c494bd2b546cc56 has been implemented, when a request returns intermediate 100 responses, the last 100 response stays in the status field of my `ReponseWriter`, which causes `MyModifyResponse` to fail.


### What did you expect to see?

I expected the `ResponseWriter` to return to its original state once the `transport.RoundTrip(outreq)` is done, and the status returned is not `1XX`.
Repository: pytorch
Issue: Inductor Channels-last slowdown
Labels: triaged,oncall: pt2,module: inductor

### 🐛 Describe the bug

This internal model gets slower with layout optimizations. I haven't root-caused the bad conv yet: P1363608493

### Error logs

..

### Minified repro

master

### Versions

master

cc @ezyang @msaroufim @bdhirsh @anijain2305 @chauhang @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @ColinPeppler @amjames @desertfire
Repository: pytorch
Issue: move label_to_label.yml to an issue?
Labels: triaged,better-engineering,actionable,module: devx

Today there are rules for adding labels if a label exists already. These are specified in [label_to_label.yml](https://github.com/pytorch/pytorch/blob/main/.github/label_to_label.yml). Would it be possible to read this from an issue instead of a checked-in yaml? Reading from the issue has the following benefits:

- it lets us modify the file without waiting for code review. This is useful to test label configurations (if some of them generate too much noise, then I want to turn them off).
- it is more discoverable



cc @ZainRizvi @kit1980 @huydhn @clee2000
Repository: next.js
Issue: Enabling `experimental.reactCompiler` causes hydration error when using styled-jsx
Labels: bug

### Link to the code that reproduces this issue

https://github.com/marmalade-labs/react-compiler-styled-jsx

### To Reproduce

1. Start the dev server `bun dev`
2. Load the page http://localhost:3000/
3. Notice the hydration mismatch error printed in the Console

### Current vs. Expected behavior

## Current behavior

The styled-jsx ID is successfully rendered on the server, but it is not being rendered on the client
![image](https://github.com/vercel/next.js/assets/85196623/715c582e-6fd5-4511-a6e5-a2663ae4c082)

## Expected behavior

The styled-jsx ID should be present in both the server and client output


### Provide environment information

```bash
Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP PREEMPT_DYNAMIC Fri, 17 May 2024 16:56:38 +0000
  Available memory (MB): 31884
  Available CPU cores: 8
Binaries:
  Node: 18.20.2
  npm: 10.8.0
  Yarn: 1.22.22
  pnpm: 8.15.5
Relevant Packages:
  next: 14.3.0-canary.72 // Latest available version is detected (14.3.0-canary.72).
  eslint-config-next: 14.3.0-canary.72
  react: 19.0.0-rc-d3ce0d3ea9-20240520
  react-dom: 19.0.0-rc-d3ce0d3ea9-20240520
  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 dev (local), next build (local), next start (local), Vercel (Deployed)

### Additional context

_No response_
Repository: node
Issue: Node incorrectly responds 400 to invalid data sent after requests with `Connection: close`
Labels: http

### Version

`v23.0.0-pre`

### Platform

`Linux cef57c85a6b6 6.8.9-arch1-2 #1 SMP PREEMPT_DYNAMIC Tue, 07 May 2024 21:35:54 +0000 x86_64 GNU/Linux`

### Subsystem

`http`

### What steps will reproduce the bug?

0. Copy the following into `server.js`:
```js
require('http').createServer((request, response) => {
    let body = [];
    request.on('data', (chunk) => {
        body.push(chunk);
    }).on('end', () => {
        response.end(JSON.stringify({
            "headers": Object.keys(request.headers).map((key) => [btoa(key), btoa(request.headers[key])]),
            "body": Buffer.concat(body).toString('base64'),
            "uri": btoa(request.url),
            "method": btoa(request.method),
            "version": btoa(request.httpVersion),
        }));
    });
}).listen(80);
```

1. Run it:
```sh
node server.js
```

2. Send it a request with `Connection: close`, then send some junk data:
```sh
printf 'POST / HTTP/1.1\r\nHost: whatever\r\nConnection: close\r\nContent-Length: 0\r\n\r\nInvalid!' | nc localhost 80
```

### How often does it reproduce? Is there a required condition?

Reproduces every time with no special conditions required.

### What is the expected behavior? Why is that the expected behavior?

The expected behavior is for the server to respond to the initial request, and then close the connection without processing the invalid data.

This is the expected behavior because of the following line in RFC 9112:
> A server that receives a "close" connection option MUST initiate closure of the connection (see below) after it sends the final response to the request that contained the "close" connection option. The server SHOULD send a "close" connection option in its final response on that connection. The server MUST NOT process any further requests received on that connection.

Other servers (AIOHTTP, Apache httpd, CherryPy, Daphne, Deno, FastHTTP, Go net/http, Gunicorn, H2O, Hyper, Jetty, Libevent, Libsoup, Lighttpd, Mongoose, Nginx, Passenger, Proxygen, Apache Tomcat, Tornado, OpenWrt uhttpd, Unicorn, Waitress, WEBrick, Werkzeug) handle this in the expected way.

### What do you see instead?

The server responds 400, indicating that the invalid data was processed:
```
HTTP/1.1 400 Bad Request\r\n
Connection: close\r\n
\r\n
```

### Additional information

_No response_
Repository: neovim
Issue: Let `mksession` preserve and/or `nvim -S` respect buffer ordering
Labels: enhancement,needs:vim-patch,editor-state

### Problem

The `mksession` command is used to save a "session"[^1], which includes, but isn't limited to, the buffers that are currently open, so that they can be restored by the `-S` option at a later time. The problem is that the *order* of these buffers in your session is not actually preserved by `mksession` or honored by `nvim -S`. For example, suppose the buffers in your session looks as follows:

| file1.py | file2.py | file3.rs
| :--- | :--- | :---

You use the `mksession` command to save it and then you exit, but when you use `nvim -S` to restore your session, you typically end up with a different buffer ordering; e.g.:

| file3.rs | file1.py | file2.py
| :--- | :--- | :---

(The above is just one possibility and should not be interpreted as implying that it would predictably end up that way.)

I recall seeing an issue where some comments explained why changing buffer orderings *after* they had been created wasn't possible or desirable[^2], which, AFAIK, means that, to change buffer ordering, the only available option is for the user to close the buffers and manually re-open them in the desired order. This isn't a great user experience, IMO, especially when you work with lots of files at a time. (Note: This is about helping users keep their workspaces organized, not about trying to find open buffers.)

I don't know if this is due to `mksession` not *preserving* buffer order when it creates the `Session.vim` file in the first place or `nvim -S` not *respecting* these data when reading the `Session.vim` file to restore the user session.

The `sessionoptions` in the docs don't seem(?) to have a value that would enable, control, and/or imply the proposed behavior. Supposing, *arguendo*, that this is feasible, perhaps this behavior could either: be implied by an existing value, or be handled by a new one?

For completeness' sake I'm using the `snap` package of `nvim`, version `0.9.4`, so, if this behavior is already in some kind of roadmap for a future release, I'd appreciate being pointed to it.

Thanks.

**PS:** [This issue](https://github.com/neovim/neovim/issues/28297) may or may not be related to this.

[^1]: I may be using some terms, like "session", here a bit loosely, but I hope what I mean is clear from context.

[^2]: ~May've been related to buffer number/IDs and plugins, IIRC. Either way, the relevant point is that users can't reorder buffers, not the underlying cause.~ See [this issue](https://github.com/neovim/neovim/issues/7558).

### Expected behavior

The expected behavior would be for the buffer ordering in sessions restored by `nvim -S` to match the order they had when the `mksession` command was used to save it. For example, the buffer ordering below should be preserved/respected when saving/restoring sessions with `mksession`/`nvim -S` respectively:

| file1.py | file2.py | file3.rs
| :--- | :--- | :---
Repository: next.js
Issue: Module not found: Can't resolve '@node-rs/argon2-wasm32-wasi'
Labels: bug,Runtime

### Link to the code that reproduces this issue

https://github.com/pulgueta/OSS-Interviewer

### To Reproduce

1. Install dependencies using `bun install`
2. Add mock env variables
3. Run local dev server using `bun dev`

### Current vs. Expected behavior

Current behavior:
![image](https://github.com/vercel/next.js/assets/38195996/5b42633a-9b8c-43eb-9b0f-8cdc754e6aab)

Expected behavior: Should just work

### Provide environment information

```bash
Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 11 Pro
  Available memory (MB): 16304
  Available CPU cores: 6
Binaries:
  Node: 20.12.2
  npm: N/A
  Yarn: N/A
  pnpm: 9.0.1
Relevant Packages:
  next: 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)

Runtime

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

next dev (local)

### Additional context

My `next.config.mjs`:
```js
import { fileURLToPath } from 'node:url';

import createJITI from 'jiti';

const jiti = createJITI(fileURLToPath(import.meta.url));

jiti('./env.server.ts');

/** @type {import('next').NextConfig} */
const nextConfig = {
	poweredByHeader: false,
	reactStrictMode: true,
	logging: {
		fetches: {
			fullUrl: true,
		},
	},
	experimental: {
		serverComponentsExternalPackages: ["@node-rs/argon2"],
		staleTimes: {
			dynamic: 0,
		}
	},
};

export default nextConfig;
```
Repository: go
Issue: proposal: encoding/csv: limit record size with Reader.MaxRecordSize
Labels: Proposal,NeedsInvestigation

### Go version

go version go1.22.3 linux/amd64

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

```shell
GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/oof/.cache/go-build'
GOENV='/home/oof/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/oof/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/oof/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/linux_amd64'
GOVCS=''
GOVERSION='go1.22.3'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/home/oof/go/oof/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 -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build3135575456=/tmp/go-build -gno-record-gcc-switches'
```


### What did you do?

The encoding/csv readRecord function has this line:

```
		dst = make([]string, len(r.fieldIndexes))
```

Here is a golang program which demonstrates this bug: https://go.dev/play/p/u7OUTS71q2Y

This bug is very similar to this: https://github.com/advisories/GHSA-8v5j-pwr7-w5f8  (aka CVE-2023-24534)

I reported this through google bug bounty, but this was considered to not have big enough impact to be considered a vulnerability.

### What did you see happen?

The program allocates enormous amounts of memory based on attacker controlled input.

### What did you expect to see?

I expected the csv reader to limit the arguments passed to "make", such that the program doesn't allocate too much memory.
Repository: deno
Issue: FUTURE: `deno install` should interop with other package managers
Labels: feat,node compat

We need to make `deno install` work well with existing projects that use `npm`, `yarn`, `pnpm`, `bun`.

This entails:
1. Understand various lockfiles like `package-lock.json` or `pnpm-lock.yaml`
1. Do not reinstall dependencies if they are already up to date, based on the contents of `node_modules/` directory and the lockfile from point 1. (ref #23907)
Repository: vscode
Issue: Project Tabs on Windows
Labels: feature-request,windows,workbench-os-integration,workbench-window

<!-- ⚠️⚠️ 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. -->
The most important reason I keep circling back to Mac OS is that VsCode still does not allow tabbed opening of multiple projects on Windows...
Repository: godot
Issue: Global shader sampler variables don't store their values
Labels: bug,confirmed,topic:shaders

### Tested versions

Tested in: Godot v4.3.dev [40b4130c9] and v4.3.dev6.official [89850d553]

### System information

Godot v4.3.dev (40b4130c9) - Windows 10.0.19045 - Vulkan (Forward+) - dedicated AMD Radeon RX 580 2048SP (Advanced Micro Devices, Inc.; 31.0.21912.14) - AMD Ryzen 5 3600 6-Core Processor (12 Threads)

### Issue description

Godot don't store the data from any sampler variable type, after set the value in project settings restarting the editor make all the sampler variables go back to empty, the exception is if you use a resource already stored in your project directory, in this case the value will be preserved after the restart


https://github.com/godotengine/godot/assets/44306054/ae47ecba-60c8-42e5-b6ea-ff5119c74986


### Steps to reproduce

Create a new global shader variable in project settings of any sampler type
Create a new resource inside the variable
Close project settings and restart the editor

When you open the global shaders again the variable will be empty

### Minimal reproduction project (MRP)

No needed, any project can reproduce that.