sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: react
Issue: Bug:
Labels: Status: Unconfirmed

The custom Jest matchers introduced for async operations in the React Test Renderer (toFlushAll, toFlushThrough, toFlushAndThrow, toClearYields) throw unexpected errors in specific scenarios involving yielded values. These errors prevent the test suite from running as expected when handling complex async updates.


React version:
18.2.0

## Steps To Reproduce

1.Install React Test Renderer and add the custom Jest matchers.
2.Write a test using the toFlushAll matcher on a component rendering async updates.
3.Run the test suite and observe the unexpected behavior during flushing.

Link to code example:
link : https://codesandbox.io/p/sandbox/new
code: 
import React from "react";
import TestRenderer, { act } from "react-test-renderer";

describe("React Test Renderer Async Matchers", () => {
  it("throws an unexpected error with toFlushAll", () => {
    const MyComponent = () => {
      const [state, setState] = React.useState(0);
      React.useEffect(() => {
        setTimeout(() => setState(1), 1000);
      }, []);
      return <div>{state}</div>;
    };

    const renderer = TestRenderer.create(<MyComponent />);

    expect(() => {
      act(() => {
        jest.runAllTimers();
        renderer.unstable_flushAll(); // Fails here with an unexpected error
      });
    }).not.toThrow();
  });
});


## The current behavior
When using toFlushAll, the test fails unexpectedly with a TypeError, preventing it from completing the async operations. The issue occurs when the matcher processes components with multiple nested yields.

## The expected behavior
The toFlushAll matcher should flush all pending async updates and yield the correct values without throwing errors. It should handle components with nested async updates seamlessly.
Repository: flutter
Issue: [native assets] [testing] Cleanup fake in tests
Labels: P3,c: tech-debt,team-tool,triaged-tool

I stumbled upon some weird looking code in some of our testing fakes:

https://github.com/flutter/flutter/blob/97ca57cf0823a1948cbb6646a04054550842080d/packages/flutter_tools/test/general.shard/isolated/fake_native_assets_build_runner.dart#L25-L26

https://github.com/flutter/flutter/blob/97ca57cf0823a1948cbb6646a04054550842080d/packages/flutter_tools/test/general.shard/isolated/fake_native_assets_build_runner.dart#L37-L68

`onBuild` takes a `BuildConfig` (single hook invocation), but outputs a `BuildResult` which is the aggregated of all hook invocations. The implementation then does a loop over all packages and simply overwrites the `result` if there is more than one package with native assets. Unsurprisingly, we don't have any invocations with more than one package with native assets.

This should be rewritten in one of the two following ways:

* `final BuildOutput? Function(BuildConfig)? onBuild;` and loop over all packages and combine the results, or
* `final BuildResult? Function()? onBuild` and don't loop over the packages.

If this should be a shallow mock, it should just record what it is invoked with and not do anything fancy. So I'm leaning towards option 2.

cc @mkustermann you added the loop over the packages (presumably to get access to a `BuildConfig`), any opinions?
Repository: opencv
Issue: “cv2.CAP_PROP_POS_FRAMES” jump is incorrect
Labels: bug,category: videoio,incomplete

### System Information

Name: opencv-python Version: 4.8.0.76
System: Ubuntu 20.04
Python Version: 3.11.9

### Detailed description

I use cap.set(cv2.CAP_PROP_POS_FRAMES, start_frame) to jump to the 360th frame, with a frame rate of 60, which is 6 seconds, but I found that the frame after the jump is the video frame at the 12th second. I have only found a problem in one video,Other video frame rates are all 30 or 29，
and there is no problem in other videos. What could be the reason? Below is my code:
cap = cv2.VideoCapture(video_path)
    if not cap.isOpened():
        print(f"Error: Unable to open video file {video_path}")
        return

    # 获取视频的FPS和总帧数
    fps = cap.get(cv2.CAP_PROP_FPS)
    total_frames = int(cap.get(cv2.CAP_PROP_FRAME_COUNT))
    
    # 计算从第几帧开始
    start_frame = int(fps * start_time)

    end_frame = int(fps * end_time)

    # 跳转到起始帧
    cap.set(cv2.CAP_PROP_POS_FRAMES, start_frame)

    frame_interval = round(fps / fps_target)  # 每秒需要提取的帧数（15帧每秒）

### Steps to reproduce

Video privacy concerns make it inconvenient to upload, sorry

### Issue submission checklist

- [x] I report the issue, it's not a question
- [x] I checked the problem with documentation, FAQ, open issues, forum.opencv.org, Stack Overflow, etc and have not found any solution
- [ ] I updated to the latest OpenCV version and the issue is still there
- [x] There is reproducer code and related data files (videos, images, onnx, etc)
Repository: vscode
Issue: Source control not working after adding turborepo to project
Labels: info-needed,git

Does this issue occur when all extensions are disabled?: Yes


- VS Code Version: 
  - Version: 1.96.1 (Universal)
  - Commit: 42b266171e51a016313f47d0c48aca9295b9cbb2
  - Date: 2024-12-17T17:50:05.206Z (1 mo ago)
  - Electron: 32.2.6
  - ElectronBuildId: 10629634
  - Chromium: 128.0.6613.186
  - Node.js: 20.18.1
  - V8: 12.8.374.38-electron.0
  - OS: Darwin arm64 23.5.0
- OS and Version: MacOs sonoma 14.5

### Bug Summary and Steps to Reproduce

Bug Summary: After we added turborepo to our project, source control stopped working properly. After making a change to any file if I go to gitlens and select the file then I see "The editor could not be opened because the file was not found."

clicking on try again button I see : "Unable to read file 'git:/Users/nikunjgoyal/work/app/apps/web/Dockerfile?{"path":"/Users/nikunjgoyal/work/app/apps/web/Dockerfile","ref":""}' (Error: Unable to resolve nonexistent file 'git:/Users/nikunjgoyal/work/app/apps/web/Dockerfile?{"path":"/Users/nikunjgoyal/work/app/apps/web/Dockerfile","ref":""}')"

![Image](https://github.com/user-attachments/assets/a1a30503-d9b3-45e0-b590-663ead27106e)


Steps to reproduce:
1. Not sure how this can be reproduced

Expected behavior: I should be able to compare differences in source control
Repository: vscode
Issue: Git error dialog swap button functions
Labels: info-needed,git

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->

When an error occurs from the Git hooks, a dialog appears with buttons: 

- Open Git Log
- Show Command Output
- Cancel

The problem is that the button click events are swapped. Cancel works correctly, but the other 2 buttons are wrong.

- Open Git Log -> Shows the command output
- Show Command Output -> Opens the Git Log

The solution is simple: Either swap the button title or the button click events. But I'm not sure what component is showing this dialog. Either VSCode or [Husky](https://github.com/typicode/husky)? Background: I'm working on an Angular project using the Husky node module for Git hooks. The dialog appears when a hook task failed (e.g. linter detected a problem).


![Image](https://github.com/user-attachments/assets/1c9ba625-4d7f-47cb-8ed2-acc6c7b6c60d)

Version: 1.96.4 (user setup)
Electron: 32.2.6
Chromium: 128.0.6613.186
Node.js: 20.18.1
V8: 12.8.374.38-electron.0
OS: Windows_NT x64 10.0.26100
Repository: storybook
Issue: [Storybook 9]: Drop support for tooling/integrations/frameworks
Labels: bug,needs triage

### Describe the bug

The official support and maintenance of the following third-party toolings/integrations/frameworks will be removed in Storybook 9:

| Category | Tool | Versions |
|----------|------|----------|
| JavaScript Engine | Node.js | v18 |
| Package Manager | npm | v8, v9 |
| Package Manager | yarn | v3 |
| Package Manager | pnpm | v7, v8 |
| Renderer | React | v16, v17 (up for discussion) |
| Renderer | Angular | v15, v16, v17 |
| Renderer | Lit | v1, v2 (up for discussion) |
| Builders | Vite | v4 |
| Language | Typescript | < v4.9 (4.9 introduces satisfies support) |
| Renderer | Svelte | < v4 |
Repository: electron
Issue: Calls to window.open in offscreen documents do not work
Labels: platform/linux,bug :beetle:,34-x-y

### Preflight Checklist

- [x] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [x] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [x] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a bug report that matches the one I want to file, without success.

### Electron Version

34.0.1

### What operating system(s) are you using?

Other Linux

### Operating System Version

6.12.6-1

### What arch are you using?

x64

### Last Known Working Electron version

_No response_

### Expected Behavior

`window.open` calls in offscreen documents created with `chrome.offscreen.createDocument` routes the window open request to the webcontents window open handler set with `setWindowOpenHandler` or just opens the window in a new `BrowserWindow` and returns the `Window` object.

### Actual Behavior

`window.open` does nothing and returns null.

### Testcase Gist URL

https://github.com/BrettCleary/electron_bug_example

### Additional Information

Please see https://github.com/BrettCleary/electron_bug_example for a simple, reproducible example. I don't see an option to add an extension folder in electron fiddle and there is too much setup for a gist.

Also I know that full extension support is not a goal of core electron developers, but given that `chrome.offscreen.createDocument` works, I would expect `window.open` to work in the offscreen doc.

If you could even point me in the right direction to start troubleshooting, I could try to open a PR with a fix as well 🙏. I would love the opportunity to help with core electron development 🚀.
Repository: vscode
Issue: Crashing when clicking on File menu with native title bar
Labels: bug,upstream,freeze-slow-crash-leak,upstream-issue-linked,chromium,mitigated


Type: <b>Bug</b>

Steps to Reproduce:

1. Arch linux with wayland (hyprland compositor)
2. Hover/click the file menu
2. All windows crash

This looks very similar to the issue discussed at https://github.com/microsoft/vscode/issues/230604

But at least for me, I'm on latest versions and made sure that the recommended workaroudn of removing meta/super key from the keybind is applied, still - vscode crashes for me.

Still happens if I launch with `code --disable-extensions`

If I downgrade to 1.94.0 it no longer crashes but I cannot use extensions such as GH copilot.

VS Code version: Code 1.96.4 (cd4ee3b1c348a13bafd8f9ad8060705f6d4b9cba, 2025-01-16T00:16:19.038Z)
OS version: Linux x64 6.12.10-arch1-1
Modes:

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

|Item|Value|
|---|---|
|CPUs|Intel(R) Core(TM) Ultra 7 165H (22 x 3804)|
|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: disabled_software<br>vulkan: disabled_off<br>webgl: enabled<br>webgl2: enabled<br>webgpu: disabled_off<br>webnn: disabled_off|
|Load (avg)|4, 2, 2|
|Memory (System)|62.24GB (51.33GB free)|
|Process Argv|-enable-features=UseOzonePlatform,WaylandWindowDecorations --ozone-platform=wayland --crash-reporter-id 83481648-87d4-4456-9caf-70c8cdfed42f|
|Screen Reader|no|
|VM|0%|
|DESKTOP_SESSION|undefined|
|XDG_CURRENT_DESKTOP|Hyprland|
|XDG_SESSION_DESKTOP|Hyprland|
|XDG_SESSION_TYPE|wayland|
</details><details>
<summary>A/B Experiments</summary>

```
vsliv368:30146709
vspor879:30202332
vspor708:30202333
vspor363:30204092
vswsl492cf:30256860
vscod805:30301674
binariesv615:30325510
vsaa593:30376534
py29gd2263:31024239
vscaat:30438848
c4g48928:30535728
azure-dev_surveyone:30548225
a9j8j154:30646983
962ge761:30959799
pythonnoceb:30805159
pythonmypyd1:30879173
2e7ec940:31000449
pythontbext0:30879054
cppperfnew:31000557
dsvsc020:30976470
pythonait:31006305
dsvsc021:30996838
dvdeprecation:31068756
dwnewjupytercf:31046870
nativerepl2:31139839
pythonrstrctxt:31112756
nativeloc2:31192216
cf971741:31144450
iacca1:31171482
notype1cf:31157160
5fd0e150:31155592
dwcopilot:31170013
stablechunks:31184530
6074i472:31201624
dwoutputs:31217127
hdaa2157:31222309
copilot_t_ci:31222730

```

</details>

<!-- generated by issue reporter -->
Repository: react
Issue: [DevTools Bug]:  Support Iterables in React DevTools
Labels: Type: Bug,Status: Unconfirmed,Component: Developer Tools

### Website or app

React DevTools

### Repro steps

1.Open a React app using React 19.0.0.
2.Pass an Iterable<T> to a component's props or state.
3.Inspect the component using React DevTools.
4.Observe the display or handling of the Iterable.

### How often does this bug happen?

Every time

### DevTools package (automated)

_No response_

### DevTools version (automated)

_No response_

### Error message (automated)

_No response_

### Error call stack (automated)

```text

```

### Error component stack (automated)

```text

```

### GitHub query string (automated)

```text

```
Repository: terminal
Issue: The lowercase I glyph (U+0069) in JuliaMono renders incorrectly
Labels: Issue-Bug,Needs-Triage

### Windows Terminal version

1.22.241118002-preview, also happens on 1.21.3231.0

### Windows build number

10.0.26100.2894

### Other Software

_No response_

### Steps to reproduce

1. Download the JuliaMono font if you haven't yet.
2. Set the terminal font to JuliaMono.
3. Open a terminal and type in "i". The glyph renders incorrectly for me.

### Expected Behavior

I was expecting this:
![Image](https://github.com/user-attachments/assets/abc70cee-b149-4586-9e1e-923ead8d39c9)
Note the serifs in the lowercase I.

### Actual Behavior

I got this behavior:
![Image](https://github.com/user-attachments/assets/e8f682d0-f3bc-4792-becf-2bbcbad68d4c)

Some notes:
- Other variations of the lowercase I (î, ï, ı etc.) render with serifs.
- Uppercase I renders with serifs, as seen in the picture.
Repository: react
Issue: Clarify Behavior of useSyncExternalStore When Using Server-Side Rendering (SSR)
Labels: Status: Unconfirmed

# Title: 
Clarify Behavior of useSyncExternalStore When Using Server-Side Rendering (SSR)

## Description:
After reviewing PR #29760, which addresses the optimization of useSyncExternalStore in React, I noticed that the behavior of this hook when used in server-side rendering (SSR) scenarios isn't clearly documented. Specifically, the following points need clarification: How should developers manage subscriptions during SSR? What best practices should be followed to avoid potential inconsistencies when hydrating the client-side store?

<!--
  Please provide a clear and concise description of what the bug is. Include
  screenshots if needed. Please test using the latest version of the relevant
  React packages to make sure your issue has not already been fixed.
-->

React version: 19

## Steps To Reproduce

1. Set up the environment: Include details about the environment where the issue occurs (e.g., React version, Node.js version, browser, etc.). 
2. Create a minimal project: Describe how to create a minimal reproducible example that isolates the bug (e.g., a simple React app using create-react-app). 
3. Write relevant code: Provide the key parts of the code where the issue happens (e.g., using a specific React feature, hook, or component). 
4. Run the project: Explain how to execute the project to trigger the bug. 
5. Observe the behavior: Describe what happens when the steps are followed (the actual behavior), compared to what you expected to happen.

<!--
  Your bug will get fixed much faster if we can run your code and it doesn't
  have dependencies other than React. Issues without reproduction steps or
  code examples may be immediately closed as not actionable.
-->

Link to code example:

<!--
  Please provide a CodeSandbox (https://codesandbox.io/s/new), a link to a
  repository on GitHub, or provide a minimal code example that reproduces the
  problem. You may provide a screenshot of the application if you think it is
  relevant to your bug report. Here are some tips for providing a minimal
  example: https://stackoverflow.com/help/mcve.
-->

Please use one of the following techniques to produce a simple, replicable sample of the bug:

Give a link to a CodeSandbox project that illustrates the problem.
GitHub Repository: Provide a link to a small project on GitHub that replicates the issue.
Inline Code: Use appropriate formatting to include the code right in the bug report if it is brief and simple.

## The current behavior
There isn't much advice on SSR-specific circumstances in the present material.

## The expected behavior
The documentation should explicitly detail how useSyncExternalStore interacts with SSR.
Provide examples of correct usage in SSR and hydration contexts.

## References
- Related Pull Request: [29760](https://github.com/facebook/react/pull/29760)
Repository: godot
Issue: There is no order in calling method _input_event() of Area2D. Expectation is order by node position in sence tree
Labels: discussion,documentation,topic:physics

### Tested versions

4.3-stable

### System information

MacOS 15

### Issue description

See the picture below, i have created a minimal reproduction project following.

This issue make it impossible to control the propagation order of input event.

![Image](https://github.com/user-attachments/assets/598e5bfe-e9a5-476f-8d6f-7ad74edc9f4e)

### Steps to reproduce

NA

### Minimal reproduction project (MRP)

[buttest.zip](https://github.com/user-attachments/files/18517822/buttest.zip)
Repository: bitcoin
Issue: test: intermittent issue in p2p_1p1c_network.py 
Labels: CI failed

Looks like this still happens: https://github.com/bitcoin/bitcoin/pull/31713#issuecomment-2609212276

So this is likely a non-timeout issue. Note that the test has immediate tx-relay (`self.noban_tx_relay`) enabled, so trickle delay should not be an issue.

_Originally posted by @maflcko in https://github.com/bitcoin/bitcoin/issues/31701#issuecomment-2609226329_
Repository: vscode
Issue: VSCode will rollback file content
Labels: workbench-copilot


Type: <b>Bug</b>

I am using vs2022 and vscode for same folder, but vscode will rollback other editor's change. 
First use other editor change the file, save, then use vs code open it, the file will be rollback,  I tested , the reason is vs code will use cache "C:\Users\qwe\AppData\Roaming\Code", if delete this folder, it will fix, but vs code do not provide a option to disable the "cache",  
Please fix the bug, or there is another way to fix this  please tell me , thank you!

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

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

|Item|Value|
|---|---|
|CPUs|Intel(R) N100 (4 x 806)|
|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.68GB (3.70GB free)|
|Process Argv|--crash-reporter-id 55627040-681b-4624-ae9b-2941d63e8d17|
|Screen Reader|no|
|VM|40%|
</details><details><summary>Extensions (9)</summary>

Extension|Author (truncated)|Version
---|---|---
copilot|Git|1.258.0
copilot-chat|Git|0.23.2
better-cpp-syntax|jef|1.27.1
marscode-extension|Mar|1.1.58
cmake-tools|ms-|1.19.52
cpptools|ms-|1.22.11
cpptools-extension-pack|ms-|1.3.0
BuildOutputColorizer|Ste|0.1.8
cmake|twx|0.0.17

(1 theme extensions excluded)

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

```
vsliv368cf:30146710
vspor879:30202332
vspor708:30202333
vspor363:30204092
vswsl492cf:30256860
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
2f103344:31071589
nativerepl1:31139838
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: rust
Issue: Cleanup "no panic support" tests
Labels: C-cleanup,A-testsuite,T-compiler,E-medium,A-panic

There are a bunch of tests that say `ignore-wasm` or `ignore-emscripten` or `ignore-$platform` with a comment "no panic support" or "no panic". It would be good to audit them and see if one or more of the following capability-based conditional test execution directives can be used instead:

- `//@ needs-unwind`
- `//@ needs-threads`
- `//@ needs-subprocess`[^1]

If those are not sufficient, it would be good to improve the ignore reason anyway.

[^1]: I'm still working on implementing this directive over at #128295.
Repository: angular
Issue: Add field to ResourceLoaderParams to find out whether the loader is triggered for the first time
Labels: area: core,state: has PR,core: reactivity,cross-cutting: signals

### Which @angular/* package(s) are relevant/related to the feature request?

_No response_

### Description

Sometimes, it's necessary to determine whether the loader was triggered for the first time. Before 19.1.x, we could have checked `param.previous.status` for Idle, but now, this status is already set to `loading` initially.


### Proposed solution

Hence, I'd like to propose another way to achieve the same, e.g., a `first` flag (similar to the first flag in `ngOnChanges`).


### Alternatives considered

We could use a flag in userland. This is doable and can be hidden in a helper function wrapping the loader. However, I assume using a first flag is easier.
Repository: pytorch
Issue: Is there a PyTorch version that can work properly on the Thor platform based on the Blackwell architecture?
Labels: module: cuda,triaged

Is there a PyTorch version that can work properly on the Thor platform based on the Blackwell architecture? I encounter many errors when compiling PyTorch source code on the Thor platform, and I don't know how to solve them. Is there any expert who can help me

cc @ptrblck @msaroufim @eqy
Repository: excalidraw
Issue: Feature: both a background color and a scratch fill type?
Labels: enhancement

I've noticed that quite often I need to stack shapes on top of one another for some fancier constructions. I use the non-solid fill types to highlight various things, but given that their background is transparent (apart of the shading), stacking them leaks the thing underneath. My current solution is to have 2 of every shape. An "underlay" with a solid white color, and then my actual shape on top with the needed shading.

<img width="669" alt="Image" src="https://github.com/user-attachments/assets/08a28964-2eae-4247-a791-f17606115aeb" />

As seen on the above image, this does work, but it needs a lot of effort to duplicate all shapes and handle overlaps between them, so sometimes I end up forgetting or just not wanting to bother (see the outer red shape's 4 corners, each bleeding the black strokes from underneath).

Wondering if it would be an interesting idea to add a non-transparent option for the shaded fill type? I'm aware that this would all of a sudden require *2* background colors, so happy to be told no, just thought I'd bring it up as food for thought.