sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: next.js
Issue: SWC minifier changes Temporal workflow names in turborepo setup
Labels: SWC

### Link to the code that reproduces this issue

https://github.com/njoshi22

### To Reproduce

1. Create Next app as apps/web
2. Create separate temporal packages for activities and workflows
3. Create temporal client as part of an API route apps/web and import one of the workflows from the workflows package
4. Call the temporal workflow from the NextJS client API route

### Current vs. Expected behavior

SWC minifies Temporal workflow name and it cannot be resolved against the actual workflow name within the Temporal environment. The only fix for this is to set `swcMinify: false` in next.config.js, and update manual webpack config with Terser to set `keep_fnames: true`. 

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.2.0: Fri Dec  6 19:01:59 PST 2024; root:xnu-11215.61.5~2/RELEASE_ARM64_T6000
  Available memory (MB): 16384
  Available CPU cores: 8
Binaries:
  Node: 20.15.1
  npm: 10.7.0
  Yarn: 1.22.19
  pnpm: 9.12.1
Relevant Packages:
  next: 14.2.18 // An outdated version detected (latest is 15.1.3), upgrade is highly recommended!
  eslint-config-next: 14.2.5
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.5.4
Next.js Config:
  output: N/A
```


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

SWC

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

next build (local), next start (local), Vercel (Deployed)

### Additional context

Tested this against next 14 and 15 builds
Repository: flutter
Issue: [monorepo] mac builds too slow
Labels: team-infra,P1,monorepo

`Linux mac_android_aot_engine`, `Mac mac_host_engine`, `Mac mac_ios_engine`, etc are currently the biggest source of build slowness in the PRs and the MQ. Frequently, everything else is long done, and the PR cannot land waiting for the last couple of mac build to finish, for example:

![Screenshot 2024-12-27 at 12 43 07 PM](https://github.com/user-attachments/assets/3c252af0-f694-4e18-bf9d-d65edc9caede)

We should really look into optimizing those. A few possible directions:

* **More optimal builds**: some drones take way too much time, like [host_debug](https://ci.chromium.org/ui/p/flutter/builders/prod/Mac%20Production%20Engine%20Drone/552325/overview) and [mac_debug_arm64](https://ci.chromium.org/ui/p/flutter/builders/prod/Mac%20Production%20Engine%20Drone/552333/overview). Are they building too much? Can we split the work into smaller pieces?
* **Retry-friendly sharding**: for example, [mac_host_engine](https://ci.chromium.org/ui/p/flutter/builders/prod/Mac%20mac_host_engine/13648/overview) schedules 18 build drones. If any one of them fails, all 18 builds have to be retried. We could instead have several builders each containing fewer drones, so if you need to retry one, you have to redo less work.
* **Upload artifacts from drones**: [this builder](https://ci.chromium.org/ui/p/flutter/builders/prod/Mac%20mac_host_engine/13648/overview) downloads artifacts built by drones one by one in a series of 2-minute tasks, then spends another 2.6 minutes uploading them to GCS. Instead, each drone could immediately upload its artifacts to GCS without having to download anything.
Repository: flutter
Issue: Flutter dashboard golden-files should support Mac or use Skia Gold
Labels: team-infra,P2,c: tech-debt

Golden-file matching in `flutter/cocoon` [uses local-file comparison, but only runs on Linux](https://github.com/flutter/cocoon/blob/6c83f7fa4064eb18a2ae0f68262d0bd03c2d6d66/dashboard/test/utils/golden.dart#L31).

This means with a Mac or WIndows machine, I cannot make any UI-impacting changes to coocon without getting another machine. Either it should be:

- possible to use any machine to generate these golden files;
- the golden files should be removed entirely;
- checking the goldens should be moved to a bringup task that can be fixed periodically;
- ... or, Skia Gold should be used like it is on our other repos
Repository: flutter
Issue: Undismissable "Android x86 targets" warning on `flutter build apk`
Labels: platform-android,tool,P2,team-android,fyi-tool

When I run `flutter build apk --debug` using the main/master channel, I get the following warning:
```
$ flutter build apk --debug

Support for Android x86 targets will be removed in the next stable release after 3.27.
See https://github.com/flutter/flutter/issues/157543 for details.
Running Gradle task 'assembleDebug'...                              3.2s
✓ Built build/app/outputs/flutter-apk/app-debug.apk
```

I don't mind that support for those targets is going away. But now that I've seen the warning, I would like to get it to stop.

(In general I try to keep my tree in a state where we don't have noise from warnings we're not planning to take any action on, so that when a new warning appears we can see it and take care of it.)

The warning text doesn't offer a way to acknowledge the warning so as to get it to stop. I don't see such a way on the linked page https://github.com/flutter/flutter/issues/157543, either.

It looks like the warning is from https://github.com/flutter/flutter/issues/158953 / https://github.com/flutter/flutter/pull/159750. I suppose one good way to silence it would be to stop building for x86. Is there a clean way to do that by editing my `build.gradle`?

If there is a good clean answer already for how to suppress the warning, then that should be added to #157543, since that's the page linked to from the warning.

(I'm starting this fresh issue rather than comment on #157543 just because I don't want discussion to clutter up the thread people will see when following the link from the warning.)
Repository: next.js
Issue: Turbo loader options type too strict
Labels: TypeScript

### Link to the code that reproduces this issue

https://github.com/Netail/repro-typescript-next-config

### To Reproduce

1. Install dependencies; `yarn install`
2. Inspect `next.config.ts`
3. Svgr options clash with turbo options type

### Current vs. Expected behavior

The turbo loader options type are a bit too strict compared to what's allowed by e.g. the SVGR plugin options

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.1.0: Thu Oct 10 21:03:15 PDT 2024; root:xnu-11215.41.3~2/RELEASE_ARM64_T6000
  Available memory (MB): 32768
  Available CPU cores: 10
Binaries:
  Node: 22.11.0
  npm: 10.9.0
  Yarn: 1.22.22
  pnpm: 9.6.0
Relevant Packages:
  next: 15.1.3 // Latest available version is detected (15.1.3).
  eslint-config-next: N/A
  react: 19.0.0
  react-dom: 19.0.0
  typescript: 5.7.2
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

TypeScript

### Which stage(s) are affected? (Select all that apply)

next dev (local)

### Additional context

_No response_
Repository: react-native
Issue: Unexpected color given in StatusBar._updatePropsStack when using PlatformColor for theming
Labels: Issue: Author Provided Repro,Component: StatusBar

### Description

Setting a `PlatformColor` value as the `backgroundColor` prop of `StatusBar` causes an "Unexpected color given in StatusBar._updatePropsStack" error.

### Steps to reproduce

1. Install and run the application on an Android device or emulator which supports Material You theming with `npm run android`
2. Notice the background colour was appropriately applied to the `View` defined in line 27
3. Uncomment line 25 (`StatusBar.backgroundColor`)
4. The app throws an "Unexpected color given in StatusBar._updatePropsStack" error

### React Native Version

0.76.5

### Affected Platforms

Runtime - Android

### Output of `npx react-native info`

```text
System:
  OS: macOS 15.1.1
  CPU: (8) arm64 Apple M1
  Memory: 121.88 MB / 8.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 23.3.0
    path: /opt/homebrew/bin/node
  Yarn:
    version: 1.22.22
    path: /opt/homebrew/bin/yarn
  npm:
    version: 10.9.0
    path: /opt/homebrew/bin/npm
  Watchman:
    version: 2024.11.25.00
    path: /opt/homebrew/bin/watchman
Managers:
  CocoaPods: Not Found
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 24.2
      - iOS 18.2
      - macOS 15.2
      - tvOS 18.2
      - visionOS 2.2
      - watchOS 11.2
  Android SDK:
    API Levels:
      - "28"
      - "29"
      - "30"
      - "31"
      - "32"
      - "33"
      - "34"
      - "35"
    Build Tools:
      - 28.0.3
      - 29.0.2
      - 30.0.2
      - 30.0.3
      - 31.0.0
      - 33.0.0
      - 34.0.0
      - 35.0.0
    System Images:
      - android-24 | Google APIs ARM 64 v8a
      - android-24 | Google APIs Intel x86 Atom
      - android-24 | Google APIs Intel x86 Atom_64
      - android-29 | Google APIs ARM 64 v8a
      - android-31 | Google Play ARM 64 v8a
      - android-32 | Google Play ARM 64 v8a
      - android-S | Google Play ARM 64 v8a
    Android NDK: Not Found
IDEs:
  Android Studio: 2024.1 AI-241.18034.62.2411.12071903
  Xcode:
    version: 16.2/16C5032a
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 17.0.13
    path: /usr/bin/javac
  Ruby:
    version: 2.7.5
    path: /Users/marin/.rvm/rubies/ruby-2.7.5/bin/ruby
npmPackages:
  "@react-native-community/cli":
    installed: 15.0.1
    wanted: 15.0.1
  react:
    installed: 18.3.1
    wanted: 18.3.1
  react-native:
    installed: 0.76.5
    wanted: 0.76.5
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: true
iOS:
  hermesEnabled: Not found
  newArchEnabled: false
```


### Stacktrace or Logs

```text
(NOBRIDGE) ERROR  Invariant Violation: Unexpected color given in StatusBar._updatePropsStack
```


### Reproducer

https://github.com/Glavotaner/InvariantStatusBar

### Screenshots and Videos

_No response_
Repository: flutter
Issue: Preserve file date (mtime) for images/files picked
Labels: c: new feature,platform-android,p: image_picker,package,c: proposal,P2,team-android,triaged-android

### Use case

When picking a file or files, it's often useful to know when the original file was created/edited. This allows features like sorting by date as well as by file name. Unfortunately, at least on Android, the last edit date (mtime) of the temp file returned from image_picker has the date/time of when the file was selected and I haven't yet found any way to access the original file's last edit date. 

### Proposal

      final XFile? tmpFile = await ImagePicker().pickImage(
        source: ImageSource.gallery,
        preserveOriginalMtime = true,
      );
      if (tmpFile == null) {
        return null;
      }
      final lastModifiedObject = await tmpFile.lastModified();
      // prints modified time of original file instead of "right now" 
      print("Last Modified: " + lastModifiedObject.toString());
      
      /******************************/ 
      
      // Implementation, could be approximated by something like
      if (preserveOriginalMtime == true) {
            await touch(newTmpFile, await fileMtime(originalFile));
      }
Repository: rust
Issue: Unexpected static lifetime requirement for nested boxed closures with generic parameters
Labels: T-compiler,C-bug,T-types,needs-triage

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

I tried this code:

```rust
type BoxedClosure<U> =
    Box<dyn for<'e> Fn(&'e Context<'e, U>) -> bool + Sync + Send + 'static>;

pub struct CompiledExpr<U>(BoxedClosure<U>);

impl<U> CompiledExpr<U> {
    pub fn new(
        closure: impl for<'e> Fn(&'e Context<'e, U>) -> bool + Sync + Send + 'static,
    ) -> Self {
        CompiledExpr(Box::new(closure))
    }
}

pub struct Context<'e, U> {
    data: &'e str,
    userdata: U,
}

pub fn compile1<U>() -> CompiledExpr<U> {
    CompiledExpr::new(|ctx| ctx.data == "rust")
}

pub fn compile2<U>() -> CompiledExpr<U> {
    let e = compile1::<U>();
    CompiledExpr::new(move |ctx| (e.0)(ctx))
}
```

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=c96c451d36a64d657cdfecc7c5185f31

I expected to see this happen: successful compilation 

Instead, this happened:
```
error[E0310]: the parameter type `U` may not live long enough
  --> src/lib.rs:25:5
   |
25 |     CompiledExpr::new(move |ctx| (e.0)(ctx))
   |     ^^^^^^^^^^^^^^^^^
   |     |
   |     the parameter type `U` must be valid for the static lifetime...
   |     ...so that the type `U` will meet its required lifetime bounds
   |
help: consider adding an explicit lifetime bound
   |
23 | pub fn compile2<U: 'static>() -> CompiledExpr<U> {
   |                  +++++++++
```

I am not exactly sure its a bug per say, but from my perspective, this is relatively surprising that this code fails to build.
The `'static` bound is on the boxed dyn object itself and not on the parameters of the boxed closure.
Its not clear why U should be `'static` when `Context`  which holds `U` is not.

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
rustc 1.83.0 (90b35a623 2024-11-26)
binary: rustc
commit-hash: 90b35a6239c3d8bdabc530a6a0816f7ff89a0aaf
commit-date: 2024-11-26
host: x86_64-unknown-linux-gnu
release: 1.83.0
LLVM version: 19.1.1
```
Repository: pytorch
Issue: Unnecessary CPU to GPU copies within flex_attention
Labels: triaged,oncall: pt2,module: pt2-dispatcher,module: flex attention

There are a few unnecessary CPU to GPU copies within flex_attention that cause unnecessary `cudaStreamSynchronize`s to occur. This decreases GPU utilization.

## Note

The below is based on a profiling run without `torch.compile`. I haven't looked at profiles of the compiled version in depth yet, but based on a quick glance, the second issue with `index_put_` seems to go away when compiled.

(My compiled tests were run with a patch for the first issue below so the results don't confirm whether the patch is necessary or if `compile` fixes it)

## Example 1

This one happens during every execution of attention:
https://github.com/pytorch/pytorch/blob/fe398de769480ceb943d3ae37551a29954bbb147/torch/_higher_order_ops/flex_attention.py#L189

That line creates a `-inf` tensor on CPU and copies it to GPU (along with a synchronize). It should be replaced with

```py
torch.full((), -float("inf"), dtype=working_precision, device=scores.device),
```

I put up a PR to fix it: #143928

## Example 2

In the following code, several `cudaStreamSynchronize`s happen within `aten::index_put_` (the `dense_mask[row_indices, valid_indices] = 1 ` line).

https://github.com/pytorch/pytorch/blob/fe398de769480ceb943d3ae37551a29954bbb147/torch/nn/attention/flex_attention.py#L152-L166

My profiling shows 3 `cudaStreamSynchronize`s per `create_dense_one` call (which is called multiple times in a single `create_block_mask` call). I was able to decrease it to 2 synchronizes by replacing

https://github.com/pytorch/pytorch/blob/fe398de769480ceb943d3ae37551a29954bbb147/torch/nn/attention/flex_attention.py#L165

with 

```py
dense_mask[row_indices, valid_indices] = torch.ones((), dtype=torch.int32, device=device)
```

The other two synchronizes are also within `aten::index_put_`, but they didn't jump out to me based on a cursory scan of the code.

cc @zou3519 @bdhirsh @penguinwu @yf225 @Chillee @drisspg @yanboliang @BoyuanFeng @chauhang @ydwu4
Repository: excalidraw
Issue: Rescaling Shapes Doesn't Work!
Labels: bug

Many of you might know that rescaling the shapes doesn't work as the shapes resize but the strokes are too thick when risized very much! 

I have also noticed that resizing the texts does work! 
So it means that rescaling the shapes properly is possible! 
Just we need to pay some attention towards this corner of excalidraw.

**NOTE** - I am talking about rescaling the shapes *down*.
Repository: react
Issue: Bug: Chrome dev tools memory leak heads up
Labels: Status: Unconfirmed

TLDR: There is a bug with Chrome dev tools that prevents nodes to be garbage collected ( detached nodes )

I noticed a lot of detached nodes when navigating in my Vite react 18 app.
Thought it was something with react-router, but then tried with tanstack router and there was the same issue.
Later I could reproduce the bug with raw react code. So I spent last few days deep diving into react source code until it lead to pure JavaScript events causing this...

By the end I figured out that it was chrome dev tools causing this, they start tracking on all events that won't allow garbage collection or something like that. And it is relatively new bug.
  
Tested with chrome 83 and 104. No issues with detached nodes...
Not sure which version of chrome introduced this. But beware memory leak bug reports that could come soon.

Here is the video of the same code with chrome 104 (left) and chrome 131 (right)


https://github.com/user-attachments/assets/926bb228-c9dc-4ccd-aa70-f34051cf64bb







React version: Tested with 16, 18 and 19

## Steps To Reproduce
1. Open codesandbox. There is a button called "open in a new tab", click it.
![image](https://github.com/user-attachments/assets/f14a27e0-62c1-4e25-9479-4ff21f65ebcf)

2. Open chrome dev tools.
3. In the video I used performance monitor. But you can track memory leaks however you want in Memory tab.
4. Each time you click on event button and then on render button it will fail to garbage collect previous nodes.

### To make sure that it is chrome dev tools and not react.
1. Open the same sandbox preview in new tab. Don't open dev tools yet.
2. Start clicking on event and render buttons dozen times.
3. Open dev tools and see that there are no detached nodes.


Link to code example: https://codesandbox.io/p/sandbox/lingering-bash-lschws

## The current behavior
Fails to garbage collect unused nodes

## The expected behavior
Should garbage collect
Repository: go
Issue: x/crypto/ssh: `ParseRawPrivateKey` should return `PassphraseMissingError` for `ENCRYPTED PRIVATE KEY`
Labels: NeedsInvestigation

### Go version

go1.23.4

### Output of `go env` in your module/workspace:

```shell
N/A
```


### What did you do?

I was validating a [Box-generated private key](https://github.com/box/developer.box.com/blob/d7a17fc79446b32f02e1ddb8e0043b9587882710/content/guides/authentication/jwt/with-sdk.md?plain=1#L65) using `ssh.ParseRawPrivateKey` and encountered an unexpected error. 

**Reproducer:** https://go.dev/play/p/mX6cEyGa7FO

( The private key is inert and was generated with: `openssl genpkey -algorithm RSA -aes256 -out encrypted_private_key.pem`)

### What did you see happen?

The function fails due to "ENCRYPTED PRIVATE KEY" not being a supported key type.
```
panic: ssh: unsupported key type "ENCRYPTED PRIVATE KEY"
```


### What did you expect to see?

The function should actually return `PassphraseMissingError`, per the documentation:

> If the private key is encrypted, it will return a PassphraseMissingError.
https://github.com/golang/crypto/blob/b4f1988a35dee11ec3e05d6bf3e90b695fbd8909/ssh/keys.go#L1230-L1233
Repository: next.js
Issue: Boundary Serialization - `Props must be serializable for components in "use client" file` warning
Labels: Linting,Partial Prerendering (PPR)

### Link to the code that reproduces this issue

https://github.com/inducingchaos/riley-barabash

### To Reproduce

**(Ignore code repro - SEE https://github.com/vercel/next.js/discussions/46795)**

In my experience: just create any component in a `"use client"` file that accepts a function, dispatch for state, or anything that is non-serializable as props.

### Current vs. Expected behavior

Current: Typescript (Next.js version) will give a warning (the title) to either a) make props serializable, or b) to postfix the prop name with 'Action'. This has led to an unnecessary amount of renamings simply to avoid this warning - where the majority of cases **don't have anything to do with Server Actions at all.**

Expected: No warnings when passing props unrelated to SA's or the client-server boundary, especially in cases where client components are layered.

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: x64
  Version: Darwin Kernel Version 24.0.0: Mon Aug 12 20:54:30 PDT 2024; root:xnu-11215.1.10~2/RELEASE_X86_64
  Available memory (MB): 32768
  Available CPU cores: 16
Binaries:
  Node: 22.9.0
  npm: 10.8.3
  Yarn: N/A
  pnpm: 9.12.0
Relevant Packages:
  next: 15.1.1-canary.16 // There is a newer canary version (15.1.1-canary.22) available, please upgrade! 
  eslint-config-next: 14.2.11
  react: 19.0.0-rc-603e6108-20241029
  react-dom: 19.0.0-rc-603e6108-20241029
  typescript: 5.6.2
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

Developer Experience, Linting, Partial Prerendering (PPR)

### Which stage(s) are affected? (Select all that apply)

next dev (local)

### Additional context

Didn't provide a repro because I'm lazy and I think there's enough context within the discussion thread I linked.

See: https://github.com/vercel/next.js/discussions/46795
Repository: kubernetes
Issue: apiserver healthz should check etcd override endpoints
Labels: kind/bug,sig/api-machinery,triage/accepted

### What happened?

It seems the apiserver will fail bootstrap if the etcd override endpoint is not healthy.
But after the bootstrap completes, if the etcd override endpoint become unhealthy, the apiserver health check will still report OK while `kubectl get cs` will report etcd override endpoint is not healthy.

### What did you expect to happen?

APIserver health check should report unhealthy when an etcd override endpoint is unhealthy.

### How can we reproduce it (as minimally and precisely as possible)?

Run 2 etcd clusters: one for events and one for the other resources. Then configure apiserver to use the event etcd using the `--etcd-servers-overrides` flag. After the apiserver complete the bootstrap, kill the event etcd.
You will be able to see APIServer health check still reporting OK.

### Anything else we need to know?

_No response_

### Kubernetes version

1.32. I think I have seen this issue in older version as well.

### Cloud provider

N/A

### OS version

<details>

```console
# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here
```

</details>


### Install tools

<details>

</details>


### Container runtime (CRI) and version (if applicable)

<details>

</details>


### Related plugins (CNI, CSI, ...) and versions (if applicable)

<details>

</details>