sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: node
Issue: Set default keepAlive options when creating HTTP/S agents
Labels: https,feature request

### What is the problem this feature will solve?

Since #37184 proposal was accepted, Node's HTTP/S `globalAgent` sets the `keepAlive` option to `true` by default, with a socket timeout of 5 seconds. However, I find this is inconsistent with the observed behavior when using the `Agent` constructor, which by default returns an agent with `keepAlive` set to `false`.

### What is the feature you are proposing to solve the problem?

Set `keepAlive` to true when creating a new HTTP/S agent, as well as setting the socket timeout to 5 seconds, to equal the behavior of the `globalAgent`. However, I recognize that this change could have unintended effects for users. Additionally, the impact of setting `keepAlive` to `true` in the `globalAgent` is still under discussion (see #47130). So, please, check my alternatives too.

### What alternatives have you considered?

1. We can keep setting `keepAlive` to `false` by default, but in case it is provided, set a default socket timeout if `timeout` is not provided. I ran into this problem this week: I was using `keepAlive` without setting a `timeout` value, so sockets were not being closed after inactivity. If the server sends a FIN packet and that event is not processed by the client before sending a new request, an `ECONNRESET` error will be thrown (as observed in #47130). I found that setting `timeout` to 5 seconds, as with the `globalAgent`, greatly reduces the number of errors.
2. If, for some reason, it is discouraged to set a default `timeout` value, at least specify in [Node HTTP docs](https://nodejs.org/api/http.html#new-agentoptions) that, if it is not provided by the user, no timeout will be set (and that it could lead to possible errors as described above).

Whichever alternative is chosen, I would be more than willing to submit a PR with a solution. Thank you!

@nodejs/http (I don't know if that still works)
Repository: PowerToys
Issue: Update procedure
Labels: Needs-Triage,Needs-Team-Response

### Description of the new feature / enhancement

Have a direct link to the update process from an update available notification

### Scenario when this would be used?

Whenever an version update is notified.

### Supporting information

_No response_
Repository: godot
Issue: GPU particles don't advance if `Engine.time_scale` was just set from 0 to a higher value in a frame
Labels: discussion,topic:rendering

### Tested versions

v4.4.dev [36e6207]

### System information

Fedora Linux 41.20241107.0 (Kinoite) on Wayland - X11 display driver, Multi-window, 1 monitor - Vulkan (Forward+) - integrated AMD Radeon 780M (RADV GFX1103_R1) - AMD Ryzen 7 PRO 7840HS w/ Radeon 780M Graphics (16 threads)

### Issue description

This is relevant for the step-by-step functionality introduced with #97257. If `Engine.time_scale` was set from 0 to a higher value, GPU particles won't visually advance before the `frame_post_draw` signal by the `RenderingServer`, and due to that, it makes them stay in place.

### Steps to reproduce

Play a scene with an emitting `GPUParticles2D/3D`, pause it inside the "Game" view, and keep clicking the next frame button.

### Minimal reproduction project (MRP)

[next-frame-problem.zip](https://github.com/user-attachments/files/17669689/next-frame-problem.zip)
Repository: flutter
Issue: [Android][A11y] Figure out a way to enable accessibility for Android
Labels: team-android

### Use case

Most of the non-Flutter specific Android tools rely on accessibility API if they want to interact with Flutter apps, e.g. integration test, app crawl, or play store

Currently the Flutter does not enable the accessibility by default. We have a trigger to enable accessibility if any tool attempt to query accessibility data on FlutterView, ie. FlutterView.createAccessibilityNodeInfo.

This, however, will only enable the accessibility node info on the next frame, which means the first time they query, they will get an empty accessibility tree. They have to wait for the next frame, which we don't have a reliable way to tell except a random delay, before they can query the accessibility node info again.

The tool may bail if they don't know this mechanism, even if they do, it is still kind of inconvenient.

### Proposal

We should have a way to launch an Android Flutter app with accessibility on by default either through integration test or through a prebuilt APK.
Repository: flutter
Issue: dependabot is too chatty updating "github-actions" dependencies, stop updating patch versions
Labels: team-infra,P2,triaged-infra

For low-traffic repos like `platform_tests` most of the commits are dependabot updating the GitHub actions dependencies.  

Update [all the repositories](https://github.com/search?q=org%3Aflutter%20package-ecosystem%3A%20%22github-actions%22&type=code) to stop updating github-actions patch versions.

https://github.com/flutter/platform_tests/blob/6a78997eba85765ef06c925a0ccbd7e2ad6818da/.github/dependabot.yml#L22-L25
```diff
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "daily"
+   ignore:
+     - dependency-name: "*"
+       update-types: ["version-update:semver-patch"]
```

Example from packages:
https://github.com/flutter/packages/blob/01050136b26c5d60058b412b60b73cee4949d4ab/.github/dependabot.yml#L35-L37

And here's what the commit history looks like [platform_tests](https://github.com/flutter/platform_tests/commits/main/):

![Screenshot 2024-11-07 at 2 15 33 PM](https://github.com/user-attachments/assets/13d303f1-d127-4c3c-9e46-7b93aeb17cb9)
Repository: vscode
Issue: completions aren't provided when I've already typed a command
Labels: feature-request,terminal-suggest

I think we should look at the last word on the line if possible and provide completions. Not sure if this is a bug or feature request 🤔 .

https://github.com/user-attachments/assets/7d1beeda-b596-4857-8785-6cc3fe100f81
Repository: PowerToys
Issue: Add an option in PowerToys to promote items from "Show More Options" to main context menu in Windows 11
Labels: Needs-Triage

### Description of the new feature / enhancement

In Windows 11, the right-click context menu often hides several useful options under a secondary "Show More Options" submenu. For advanced users, navigating to these frequently used options can be inefficient. I propose adding a feature to PowerToys that allows users to select specific items from the "Show More Options" submenu and promote them to the main context menu, making them accessible with fewer clicks. This would significantly streamline workflows by reducing the need to navigate through the extra layer.

### Scenario when this would be used?

This feature is ideal for users who frequently access options like “Properties,” “Edit with…” options, or other settings hidden under "Show More Options." By promoting these items, users save time and avoid additional clicks, which is particularly useful in workflows where quick access to specific settings or tools is essential.

What is the expected behavior of the proposed feature?
Users can use PowerToys to select specific menu items in the "Show More Options" submenu and move or pin them to the main context menu. This customization should allow quick and direct access to commonly used items, making the overall user experience faster and more efficient.

### Supporting information

As a Power User on Windows 11, my workflow often involves accessing context menu items under "Show More Options." Other users in forums and community feedback pages have expressed similar frustrations about the extra layer in the menu, which adds time to common actions. Enabling users to customize the context menu in this way would align with PowerToys’ mission to enhance productivity and usability for advanced Windows users.
Repository: godot
Issue: MultiplayerSynchronizer Causes Position Data Corruption When Using CharacterBody3D Physics
Labels: bug,topic:physics,topic:multiplayer

### Tested versions

Reproducible in: 4.3.stable

### System information

Windows 10 - Godot v4.3.stable - Compatibility

### Issue description

When adding a new node to a scene and changing its authority, if that node is a CharacterBody3D node with a MultiplayerSynchronizer syncing its position across clients, the new node will default to the position of the last node of the same type spawned in the same way.

### Steps to reproduce

- Under `Debug->Custom Run Instances...` enable `Enable Multiple Instances` and set the instance count to 2.
- Launch the demo using `Run Project` (F5)
- In one window, press "Host Server" and use WASD or Arrow Keys to move the character around.
- In the other window, press "Connect to Server"
- If the nodes are using `move_and_slide`, the new player node will inexplicably teleport to the host player's position.
- To toggle the physics usage to demonstrate intended behavior, toggle comments on lines 13-15 and lines 17-18 in `player.gd`

I have also included the minimal reproduction repository on GitHub, with instructions there to reproduce the bug.

### Minimal reproduction project (MRP)


[multiplayer-sync-bug-demo.zip](https://github.com/user-attachments/files/17670275/multiplayer-sync-bug-demo.zip)

Can also be found at: https://github.com/code807/godot-multiplayer-bug-demo/tree/main
Repository: flutter
Issue: Write test case and automated test for touch within iOS platform views
Labels: platform-ios,engine,P2,team-ios,triaged-ios

In an attempt to fix https://github.com/flutter/flutter/issues/136244 this PR https://github.com/flutter/engine/pull/55724 caused a Very Bad regression which broke all touch within platform views (b/341930773#comment50) for a 1p customer and was therefore reverted.  However, we were unable to reproduce this bug with vanilla open source Flutter, even though a workaround was found in the iOS embedder.

Screen recording of bug: go/flutter-touch-bug-screenrecording

- [ ] Figure out how to reproduce the bug outside of the customer app
- [ ] Write an automated test (tracked here https://github.com/flutter/flutter/issues/156753)
Repository: godot
Issue: Linux window title momentarily displays garbled text when opening
Labels: bug,platform:linuxbsd,topic:gui

### Tested versions

4.3

### System information

fedora40

### Issue description

When I open Godot using linux Chinese environment, the window title will display a garbled code:é¡¹ç®ç®¡çâ

### Steps to reproduce

none

### Minimal reproduction project (MRP)

none

![mmexport1731022255775](https://github.com/user-attachments/assets/e52f9359-4ad2-4a99-9d67-4a3709216e64)
Repository: storybook
Issue: [Bug]: Inconsistent Render Between Canvas and Docs
Labels: bug,has workaround,addon: docs

### Describe the bug

Docs views injects parasitizing CSS on the page, impacting components rendering.
(The iframe contains code coming from both Storybook and the user's component, creating CSS conflicts.)

Canvas views does not have this problem, as the iframe is not shared between several components.

A good fix would probably be to create one iframe per component on the Docs page.

A video of the problem:
- First, in Canvas view, text color and background color are well applied.
- But then, in Docs view, background color is not applied, because some Storybook classes redefine it.
  - I need to disable some CSS classes for my background color to be applied.

https://github.com/user-attachments/assets/fe0d4ff1-015e-4f54-862f-59c104e29211


### Reproduction link

https://stackblitz.com/edit/github-npfjjs?file=README.md

In case of a package installation error, you may need to:
1. Delete the `yarn.lock` file, and...
2. Execute the `$ yarn install && yarn storybook` command to launch Storybook.

### Reproduction steps

Same as the video:
 
1. Go to the above link (stackblitz)
2. Go to the Canvas page of the component
3. Toggle light/dark (it should work)
4. Go to the Docs page
5. Toggle light/dark (only the text will change, but the background color stays light in dark mode) 

### System

Storybook Environment Info:

  System:
    OS: macOS 14.6.1
    CPU: (8) arm64 Apple M1
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 21.0.0 - ~/.nvm/versions/node/v21.0.0/bin/node
    npm: 10.2.0 - ~/.nvm/versions/node/v21.0.0/bin/npm <----- active
  Browsers:
    Chrome: 130.0.6723.117
    Safari: 17.6
  npmPackages:
    @storybook/addon-a11y: ^8.4.1 => 8.4.1 
    @storybook/addon-essentials: ^8.4.1 => 8.4.1 
    @storybook/addon-interactions: ^8.4.1 => 8.4.1 
    @storybook/addon-onboarding: ^8.4.1 => 8.4.1 
    @storybook/addon-themes: ^8.4.1 => 8.4.1 
    @storybook/blocks: ^8.4.1 => 8.4.1 
    @storybook/test: ^8.4.1 => 8.4.1 
    @storybook/vue3: ^8.4.1 => 8.4.1 
    @storybook/vue3-vite: ^8.4.1 => 8.4.1 
    eslint-plugin-storybook: ^0.10.2 => 0.10.2 
    storybook: ^8.4.1 => 8.4.1 

### Additional context

_No response_
Repository: react
Issue: [Compiler Optimization]: avoid memoizing `useState` lazy initializer functions
Labels: Component: Optimizing Compiler

### What kind of issue is this?

- [X] React Compiler core (the JS output is incorrect, or your app works incorrectly after optimization)
- [ ] babel-plugin-react-compiler (build issue installing or using the Babel plugin)
- [ ] eslint-plugin-react-compiler (build issue installing or using the eslint plugin)
- [ ] react-compiler-healthcheck (build issue installing or using the healthcheck script)

### Link to repro

https://playground.react.dev/#N4Igzg9grgTgxgUxALhAMygOzgFwJYSYAEAYhBABQAOMEVYyRwmAhgLYLJg4x6YDmAXwCUTIgB1iROIW5EA2txY4EAXSIBeIgCUELXADooYBAGUcyhBQqiNAPiaSizojAQ5YxTAgDuRACosANYIYAAyhPz+eBz+EADCEGxUUCrUtPQGrBzCTkQiANx5bh4wxEoqWewIRZiCkpJwADYsYGABwaERAtGxCUkpKo5S2ZzcvAK1zjKY41C4EDAUo6LAec5oi0QUTe5EeJpEAAwF+wDUZ6cHADxEAIwIAGyr+etEOAAWeGBVHIejU1edRAgiAA

### Repro steps

1. call `useState` with the lazy state initialiser that consumes props
2. observe the function is being cached in the compiled code despite it only ever being called once

However, I'm not 100% sure this is valid React code as the docs state:

> If you pass a function as initialState, it will be treated as an initializer function. It should be pure, should take no arguments, and should return a value of any type. React will call your initializer function when initializing the component, and store its return value as the initial state. [See an example below.](https://19.react.dev/reference/react/useState#avoiding-recreating-the-initial-state)

But this does seem like a valid use-case.

### How often does this bug happen?

Every time

### What version of React are you using?

version in playground

### What version of React Compiler are you using?

version in playground
Repository: godot
Issue: Two Identical Meshes But Only One Works with Skeleton
Labels: discussion,documentation,needs testing,topic:import

### Tested versions

4.3-stable

### System information

Godot v4.3.stable.mono - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1060 6GB (NVIDIA; 32.0.15.6094) - Intel(R) Core(TM) i5-8400 CPU @ 2.80GHz (6 Threads)

### Issue description

I have to absolutely identical meshes, both exported from Blender, one of them was exported with the Armature and the other was was exported alone.

I **already** have the skeleton for this mesh in my Godot scene, I only need to change between meshes, but for some reason it only works if I export the whole armature + mesh from blender and not only the mesh, which is all I need. It seems like the vertex groups are getting lost somewhere or not being loaded properly.

Exported w/Armature:
![image](https://github.com/user-attachments/assets/4a91b499-376b-46f4-9580-d99e13929489)

Exported only Mesh:
![image](https://github.com/user-attachments/assets/22c4ea8f-2fa3-4dc3-8c83-abc80677b71c)

Quick video:


https://github.com/user-attachments/assets/fd84bac0-77a3-4baa-a030-147b67e45573





### Steps to reproduce

1. Create an Armature in blender and animate a simple mesh
2. Import the full model to Godot (mesh + armature) everything works fine
3. Go back to blender and create/modify the mesh (just the mesh)
4. Import only the mesh into godot
5. Go into the skeleton and change the mesh for the new onw
6. It doesnt work 

### Minimal reproduction project (MRP)

[bug-report-meshes-anim.zip](https://github.com/user-attachments/files/17670795/bug-report-meshes-anim.zip)
Repository: pytorch
Issue: DTensor support for fused qkv matmul
Labels: oncall: distributed,module: dtensor

### 🚀 The feature, motivation and pitch

For transformer architecture (for example https://github.com/pytorch-labs/gpt-fast/blob/main/model.py#L195-L211) it tends to be most performant to merge the qkv matrices together. If you try to shard this concatenated tensor then the subsequent SDPA op won't be shared correctly since you need each column of q sharded with the corresponding columns of  k and v [q1,k1,v1,...], but by default the sharding will be [q1, q2, q3...] When not using DTensor this is relatively easy to get to work: https://github.com/pytorch-labs/gpt-fast/blob/main/tp.py#L73

but for DTensor the way to enable this is really unclear. is there a way to handle this type of operation with DTensor parallelization or should we just stick to normal tensor parallel support and figure out how to get it to work with our APIs?

This is currently blocking tensor parallel support in torchAO so i wanted to centralize discussion to a single location.

### Alternatives

don't use DTensor for tensor parallel

### Additional context

_No response_

cc @H-Huang @awgu @kwen2501 @wanchaol @fegin @fduwjj @wz337 @wconstab @d4l3k @c-p-i-o @tianyu-l @XilunWu
Repository: rust
Issue: Compiletest path normalization fails in windows if path is inside a string
Labels: A-testsuite,O-windows,T-bootstrap,C-bug,S-needs-repro,A-compiletest

In the initial version of https://github.com/rust-lang/rust/pull/132161,  a Windows CI job because the stdout contained a string containing the test path that wasn't normalized.

I'm pasting the error as described in https://github.com/rust-lang/rust/pull/132161#issuecomment-2442931343:


```diff
---- [ui] tests\ui\stable-mir-print\operands.rs stdout ----
$DIR\operands.rs
$DIR\operands.rs
\a\rust\rust\tests\ui\stable-mir-print\operands.rs
$DIR\operands.rs
Saved the actual stdout to "C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\test\\ui\\stable-mir-print\\operands\\operands.stdout"


226     debug x => _1;
227     debug z => _2;
228     bb0: {
-         _0 = {closure@Span { id: 105, repr: "$DIR/operands.rs:44:5: 44:19" }}(_1, _2);
+         _0 = {closure@Span { id: 105, repr: "C:/a/rust/rust/tests/ui/stable-mir-print/operands.rs:44:5: 44:19" }}(_1, _2);
231     }
232 }
```
Repository: flutter
Issue: FlutterPluginRegistrant.xcframework from release build missing _CodeSignature and dSYMs folders
Labels: platform-ios,engine,a: existing-apps,has reproducible steps,P2,team-ios,triaged-ios,found in release: 3.24,found in release: 3.27

### Steps to reproduce

When I build ios-framework for a  flutter module project(template=module) that has package dependencies, the FlutterPluginRegistrant.xcframework release bundle is missing _CodeSignature and dSYMs for "ios-arm64" platform.

Command: `flutter build ios-framework --release --no-debug --no-profile`

![image](https://github.com/user-attachments/assets/dd9af28a-2c16-4469-9135-afbacfc8da3c)

When I am using module frameworks in native iOS app, it is crashing during below line
`GeneratedPluginRegistrant.register(with: self.flutterEngine);`
I suspect it has to do with missing code signature, since there is no dSYMs I can't see detailed crash report.



### Expected results

  Flutter module release build should create _CodeSignature and dSYMs for ios-arm64 platform for bundle FlutterPluginRegistrant.xcframework

### Actual results

Flutter module release build missing _CodeSignature and dSYMs for ios-arm64 platform for bundle FlutterPluginRegistrant.xcframework

### Code sample

<details open><summary>pubspec.yaml has below dependencies:</summary>

```dart
environment:
  sdk: ^3.5.3

dependencies:
  amplify_flutter: ^2.0.0
  amplify_auth_cognito: ^2.0.0
  flutter:
    sdk: flutter
  cupertino_icons: ^1.0.8
  google_fonts: ^6.2.1
  flutter_localizations:
    sdk: flutter
  intl: any
  provider: ^6.1.2
  change_case: ^2.1.0
  flutter_launcher_icons: ^0.14.1

dev_dependencies:
  flutter_test:
    sdk: flutter
  flutter_lints: ^5.0.0
  mockito: ^5.0.0
```

</details>


### Screenshots or Video

<details open>
<summary>Screenshots / Video demonstration</summary>

[Upload media here]

</details>


### Logs

<details open><summary>Logs</summary>

```console
[Paste your logs here]
```

</details>


### Flutter Doctor output

<details open><summary>Doctor output</summary>

```console
╰─ flutter doctor
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 3.24.4, on macOS 15.0.1 24A348 darwin-x64, locale en-US)
[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
[✓] Xcode - develop for iOS and macOS (Xcode 16.0)
[✓] Chrome - develop for the web
[✓] Android Studio (version 2024.1)
[✓] IntelliJ IDEA Ultimate Edition (version 2022.3.3)
[✓] IntelliJ IDEA Community Edition (version 2021.3.3)
[✓] VS Code (version 1.95.0)
[✓] Connected device (4 available)
[✓] Network resources

• No issues found!
```

</details>
Repository: flutter
Issue: github-actions bot not closing issues.
Labels: team-infra,P2,triaged-infra

### Type of Request

bug

### Infrastructure Environment

github-actions bot

### What is happening?

I marked an issue as "waiting for customer response" 3 weeks ago, and after a period of inaction, the `github-actions` bot messaged that it was going to "reluctantly going to close this bug for now".

It didn't actually close the issue though (I guess it was feeling *very* reluctant!)

Here's the link to the issue:

* https://github.com/flutter/flutter/issues/155444

I'm leaving it open in case there's something fishy on it.

### Steps to reproduce

1. Add the `waiting for customer response` label to a flutter/flutter issue.
2. Wait 3 weeks.


### Expected results

I'd expect the issue to be *closed* after the inactivity period. The issue where I applied this label remained open.