sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: langchain
Issue: Ollama (Partner package) and cache integration not working correctly - missing filters / Community Package works
Labels: 🤖:bug

### Checked other resources

- [X] I added a very descriptive title to this issue.
- [X] I searched the LangChain documentation with the integrated search.
- [X] I used the GitHub search to find a similar question and didn't find it.
- [X] I am sure that this is a bug in LangChain rather than my code.
- [X] The bug is not resolved by updating to the latest stable version of LangChain (or the specific integration package).

### Example Code

```python
from langchain_community.cache import SQLiteCache
from langchain_ollama import OllamaEmbeddings, OllamaLLM

llm = OllamaLLM(
            model=model,
            cache=SQLiteCache(str(cache_dir / f"ollama-{model}.db")),
            temperature=0.4,
            num_ctx=8192,
            num_predict=-1,
        )
```

### Error Message and Stack Trace (if applicable)

There is no error stack as the problem is how the LLM message is being cached in SQLLite

### Description

Here is how the entries in SQLiteCache looks when langchain-ollama partner package is used

![image](https://github.com/user-attachments/assets/0b942674-8213-4345-b8c9-6bb98bf5cd81)

Whereas if the Ollama from langchain_community is used then the SQLLiteCache looks like

![image](https://github.com/user-attachments/assets/0596291e-6fc1-4a02-96c5-deb033594002)


As you can see that the entries in filter column do not include other properties like temperature, model name etc and hence when these parameters are changes the old entries for a prompt if present are picked instead of creating new


### System Info

langchain==0.2.12
langchain-chroma==0.1.2
langchain-community==0.2.11
langchain-core==0.2.28
langchain-ollama==0.1.1
langchain-openai==0.1.20
langchain-text-splitters==0.2.2
Repository: kubernetes
Issue: [FG:InPlacePodVerticalScaling] Scheduling race condition
Labels: sig/scheduling,sig/node,kind/feature,priority/important-longterm,triage/accepted

What is the desired behavior when a pod is resized in the middle of scheduling? The current behavior is that after a certain point the scheduler would not pick up the updated resources and proceed to schedule a pod to a node, even if it no longer fits. The kubelet will then reject the pod in admission (`OutOfCPU` or `OutOfMemory`).

I think we have 3 options:

1. Proceed with the current approach, and accept (document) this as a possible failure mode
2. Forbid resizing un-scheduled pods (use case is questionable)
3. Minimize (but don't eliminate) the risk by checking for changes before binding. There will always be a race condition here, since the bind request is not transactional.

I'm leaning towards the first option.

/sig node
/priority important-longterm
Repository: PowerToys
Issue: Showing what are overrides of Window / Common keys in OOBE/SCOOBE & Settings
Labels: Idea-Enhancement,Area-OOBE

### Description of the new feature / enhancement

If a common key is overrode inside of PowerToys, (Example PT Run does Alt+Space), we should make that clear to the user.

This would be need to be inside OOBE and Scoobe incase we add new functionality as well as the key shortcut control.  A user may not be aware they are overriding a behavior

As part of this work, it would be basically documenting in code https://github.com/microsoft/PowerToys/issues/179

### Scenario when this would be used?

Awareness of overrides that could have hidden impact

### Supporting information

Alt+Space is a keyshort cut people do actively use.
Repository: pytorch
Issue: Improving inductor pattern matcher's replacement graph assumptions
Labels: triaged,oncall: pt2,module: inductor

The pattern matcher assumes by default that it is safe to run functional passes on the replacement graph. The ones it runs are DCE and remove_noop_ops. We should try to change it to be more automatic and determine if those passes are safe to run (or add invariants if this is too hard, see also https://github.com/pytorch/pytorch/issues/133250). 

This is non-trivial:
- For DCE we can check if there are any mutable ops. If there are, then it's probably a bad idea to DCE
- For remove_noop_ops -- this is trickier. We cannot remove intermediate clones if they end up changing the alias relationship between the outputs and the inputs of the replacement graph.

cc @ezyang @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @ColinPeppler @amjames @desertfire
Repository: vscode
Issue: Windows 11: VScode crashed (reason: 'oom', code: '-536870904'
Labels: bug,freeze-slow-crash-leak

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
- VS Code Version: 1.92.2
- OS Version: Windows 11 Pro, Version 23H2, OS build: 22631.4037
- System RAM: 64GB
- GPU: NVidia GeForce RTX 3080, Driver: 560.81

Steps to Reproduce:

1. Start writing code.

Attempted Fixes:
1. Verified that VScode folders are not being uploaded to OneDrive (or any other cloud backup providers)
2. Deleted all VScode and Project cache files
3. Deleted VScode backups
4. Deleted .vscode from App folder
5. Deleted Windows temp files
6. Removed all extensions
7. Excluded VScode from Windows Defender
8. Verified Large File Optimizations
9. Changed paging file size from 4096 (Windows auto manage) to 9216 (min) - 196609 (max)
11. Disabled hardware acceleration

Here is one of the many .dmp files:
[c0eba4c2-10ff-48ec-94c9-66b49dd2fdfd.dmp](https://github.com/user-attachments/files/16733252/c0eba4c2-10ff-48ec-94c9-66b49dd2fdfd.dmp)

Crash report preview:

> EXCEPTION_RECORD:  (.exr -1)
> ExceptionAddress: 00007fffbb82fabc (KERNELBASE!RaiseException+0x000000000000006c)
>    ExceptionCode: e0000008
>   ExceptionFlags: 00000081
> NumberParameters: 1
>    Parameter[0]: 0000000000b1b1c7
> 
> PROCESS_NAME:  Code.exe
> 
> ERROR_CODE: (NTSTATUS) 0xe0000008 - <Unable to get error code text>
> 
> EXCEPTION_CODE_STR:  e0000008
> 
> EXCEPTION_PARAMETER1:  0000000000b1b1c7
> 
> STACK_COMMAND:  ~0s; .ecxr ; kb
> 
> SYMBOL_NAME:  code+b55379
> 
> MODULE_NAME: Code
> 
> IMAGE_NAME:  Code.exe
> 
> FAILURE_BUCKET_ID:  APPLICATION_FAULT_e0000008_Code.exe!Unknown
> 
> OSPLATFORM_TYPE:  x64
> 
> OSNAME:  Windows 10
> 
> IMAGE_VERSION:  1.92.2.0
> 
> FAILURE_ID_HASH:  {203dc02c-fd4a-1c4e-3e48-6581c93eb6d2}
Repository: flutter
Issue: Update run_verify_binaries_codesigned_tests to collect and print all the missing/unexpected binaries on failure, instead of failing-fast on the first
Labels: team-release

This was an issue in https://github.com/flutter/flutter/pull/153787.

@itsjustkevin asks
> Is it possible that the test failed only on the first binary?

I think so, based on more binaries missing from the list: https://github.com/flutter/flutter/pull/154027

The test should be updated to collect all the unexpected binaries, and print them all:
https://github.com/flutter/flutter/blob/5e194383af022816e1f551fcd16abfd8d1e54694/dev/bots/suite_runners/run_verify_binaries_codesigned_tests.dart#L150-L152
Repository: rust
Issue: Unstable Feature Usage Metrics
Labels: T-compiler,C-tracking-issue,A-metrics

## Unstable Feature Usage Metrics

Track unstable feature usage trends by Rust users.

### Motivation

* Support feature stabilization prioritization. 
* Helping teams know which unstable features to invest their energy into. 
* Evaluating how representative crates.io is as a sample of the rust ecosystem (will we see different patterns in crates.io feature usage vs private feature usage?)

### Context

* [research paper on unstable feature usage in the rust ecosystem](https://arxiv.org/pdf/2310.17186)

### Steps / History (PROVISIONAL)

- [ ] define the format the metrics will be stored in
- [ ] add flag to dump unstable feature status metrics (what features exist, if they're stable or not, both for library and lang/compiler, tidy may already support this for lib features)
- [x] add flag to enable unstable feature usage metrics in the compiler
- [ ] front end to display reports based on gathered usage and status metrics
- [ ] back end to save metrics data from published crates.io crates (private data should be anonymous and stored separately once we have established the ability to gather that in a statistically relevant volume)
- [ ] integrate with docs.rs to have it gather metrics and upload them to the backend while building newly uploaded crate versions
Repository: kubernetes
Issue: Int overflow in hpa causing incorrect replica count
Labels: kind/bug,sig/autoscaling,needs-triage

### What happened?

The setup:
I am using keda with the prometheus scaler. The query I am using, returns the lag in the message queue i am using, and the threshold is set to `0.1`.

What happened:
The lag was increasing for a long time, and the replica count reached the max setting as expected. Everything was running fine for some time. When the lag value reached `214,748,364` hpa decided to reduce the replicas from the max limit to `1`.

What I think is the problem:
When the lag passes `214,748,364`, the calculation [here](https://github.com/kubernetes/kubernetes/blob/7b80cdb66a390f225d23cd612950144e3a39d1ae/pkg/controller/podautoscaler/replica_calculator.go#L278) divides by the threshold `0.1` and it passes the max int32 value. causing hpa to scale to the minimum value, 1.
It also seems like a lot of other places in this file cast a 64 bit float to a 32 bit int. Should there maybe be a check everywhere this is done?

### What did you expect to happen?

I expected the replica count to stay at the max value. Or alternatively, get an error that we have reached the max value for an external metric value

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

Use an external metric, and set it above `214,748,364` with a threshold of `0.1`.

### Anything else we need to know?

_No response_

### Kubernetes version

<details>

```console
$ kubectl version
# paste output here
```
1.29
</details>


### Cloud provider

<details>
aws eks
</details>


### 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>
Repository: pytorch
Issue: [torch.compile] Graphs differ between 2.4 and 2.5
Labels: triaged,oncall: pt2,oncall: export

### 🐛 Describe the bug

Within Torch-TensorRT, we use [aot_export_joint_simple](https://github.com/pytorch/TensorRT/blob/main/py/torch_tensorrt/dynamo/backend/backends.py#L90-L97) to get aten level graph for TensorRT compilation. This used to return a graph with weights registered as `get_attr` nodes in the graph in Pytorch 2.4. However, this behavior seems to be changed in 2.5. All the constants are now registered as placeholders. We observed this to potentially impact performance of models. 

To reproduce: 

```py
import torch
import torch._dynamo as td
from transformers import AutoModelForCausalLM, AutoTokenizer
from torch._functorch.aot_autograd import aot_export_joint_simple
from torch._dynamo.utils import detect_fake_mode
import unittest
from torch_tensorrt.dynamo.lowering import (
    get_decompositions,
    remove_sym_nodes,
    repair_input_aliasing,
)

@td.register_backend(name="random")  # type: ignore[misc]
def aot_torch_tensorrt_aten_backend(
    gm: torch.fx.GraphModule, sample_inputs, **kwargs
) -> torch.nn.Module:

    fake_mode = detect_fake_mode(sample_inputs)

    # Place backend tracing within FakeTensor context allowing nonfake Tensors
    with unittest.mock.patch.object(
        fake_mode, "allow_non_fake_inputs", True
    ), fake_mode:

        # Invoke AOTAutograd to translate operators to aten
        gm = aot_export_joint_simple(
            gm,
            sample_inputs,
            trace_joint=False,
            decompositions=get_decompositions(
                False
            ),
        )
        print(gm.graph)
        return gm


# define the model
with torch.no_grad():
    tokenizer = AutoTokenizer.from_pretrained("gpt2")
    model = AutoModelForCausalLM.from_pretrained(
        "gpt2",
        pad_token_id=tokenizer.eos_token_id,
        use_cache=False,
        attn_implementation="eager",
    ).eval().cuda()

prompt = "I enjoy walking with my cute dog"
model_inputs = tokenizer(prompt, return_tensors="pt")
input_ids = model_inputs["input_ids"].cuda()
torch._dynamo.mark_dynamic(input_ids, 1, min=7, max=1023)
model.forward = torch.compile(model.forward, backend="random", dynamic=None)

model(input_ids)
```

Please find the attached [gm_2.4.txt](https://github.com/user-attachments/files/16733544/gm_2.4.txt) and [gm_2.5.txt](https://github.com/user-attachments/files/16733541/gm_2.5.txt) to notice the differences. 

Is there a setting to disable this behavior ? 

cc: @angelayi @avikchaudhuri 

### Error logs

_No response_

### Minified repro

_No response_

### Versions

Pytorch 2.4 and 2.5.0.dev20240822+cu124

cc @ezyang @chauhang @penguinwu @avikchaudhuri @gmagogsfm @zhxchen17 @tugsbayasgalan @angelayi @suo @ydwu4
Repository: flutter
Issue: Web SDK uses non-`DEPS`'d dependencies, and can't use the workspace as a result
Labels: engine,platform-web,P2,c: tech-debt,team-web,triaged-web

In https://github.com/flutter/engine/pull/54232, most of the engine repository moved to the pub workspace.

As of time of this writing, the web SDK and web SDK tools are _not_ included, as they do not use `DEPS`-vendored dependencies:

- https://github.com/flutter/engine/blob/main/web_sdk/web_engine_tester/pubspec.yaml
- https://github.com/flutter/engine/blob/main/web_sdk/web_test_utils/pubspec.yaml
- https://github.com/flutter/engine/blob/main/lib/web_ui/pubspec.yaml

I would be happy to review PRs or answer questions, but someone on the web team will need to own making the change:

- [ ] Making sure all packages are available on ~CIPD~ mirror, and adding them if needed
- [ ] Changing the dependencies to use the mirror'd versions, and making sure tests still pass/are not flakey
- [ ] Moving the pubspecs, now using DEPS-vendored dependencies, to the workspace
Repository: kubernetes
Issue: Migrate hack/verify-featuregates.sh and hack/update-featuregates.sh to golangci-lint plugin architecture
Labels: sig/api-machinery,kind/feature,triage/accepted

### What would you like to be added?

Recently in #125830 (as part of https://github.com/kubernetes/enhancements/issues/4330) a `static analysis script to verify new feature gates are added as versioned feature specs` was added to the code base that uses a bespoke linter setup.   This approach is temporary/alpha with the desired approach for beta of the https://github.com/kubernetes/enhancements/issues/4330 using a golangci-lint plugin (see https://github.com/kubernetes/kubernetes/pull/125830#issuecomment-2260449394)

### Why is this needed?

From comments on the initial PR https://github.com/kubernetes/kubernetes/pull/125830#issuecomment-2260449394 and some associated user issues/friction posted after this change (https://github.com/kubernetes/kubernetes/issues/126741#issuecomment-2293634664) it makes sense to migrate the current bespoke linter script and go code to instead be a golangci-lint plugin to address.  Doing so is identified as a must-do before  https://github.com/kubernetes/enhancements/issues/4330 can move to `beta` (mentioned in the above PR comment as future work) and the bug here tracks that work.  Reasons the golangci-lint plugin approach is preferred is:

- more performance (golangci-lint caching, etc)
- in line with kubernetes/kubernetes linting best practices
- removes need for `update-features` concept and helps with source of truth issues seen currently
Repository: godot
Issue: [linux] use_llvm cross compile failure
Labels: platform:linuxbsd,topic:buildsystem,needs testing

### Tested versions

4.3-stable

### System information

Yocto `scarthgap` running on Fedora 40

### Issue description

Using externally set `CC` and `CXX` will incorrectly be overwritten when using `use_llvm`.

Example external values for a cross compile:
```
export CC="riscv64-poky-linux-clang -target riscv64-poky-linux     -mlittle-endian --dyld-prefix=/usr -Qunused-arguments -fstack-protector-strong  -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/mnt/raid10/yocto/master/visionfive2/tmp/work/riscv64-poky-linux/godot/4.3/recipe-sysroot"
export CXX="riscv64-poky-linux-clang++ -target riscv64-poky-linux     -mlittle-endian --dyld-prefix=/usr -Qunused-arguments -fstack-protector-strong  -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/mnt/raid10/yocto/master/visionfive2/tmp/work/riscv64-poky-linux/godot/4.3/recipe-sysroot"
```

Build setup/compile
[run.do_compile.txt](https://github.com/user-attachments/files/16733803/run.do_compile.txt)

This patch resolves the issue:
```
diff --git a/platform/linuxbsd/detect.py b/platform/linuxbsd/detect.py
index d1de760f34..04f4662ed2 100644
--- a/platform/linuxbsd/detect.py
+++ b/platform/linuxbsd/detect.py
@@ -110,9 +110,6 @@ def configure(env: "SConsEnvironment"):
         env["use_llvm"] = True
 
     if env["use_llvm"]:
-        if "clang++" not in os.path.basename(env["CXX"]):
-            env["CC"] = "clang"
-            env["CXX"] = "clang++"
         env.extra_suffix = ".llvm" + env.extra_suffix
 
     if env["linker"] != "default":
-- 
2.46.0
```

It seems that `os.path.basename(env["CXX"])` is not correctly reading the external environment.

### Steps to reproduce

Set `CC` and `CXX` to something other than `clang` and `clang++`.  e.g.
```
export CC="riscv64-poky-linux-clang -target riscv64-poky-linux     -mlittle-endian --dyld-prefix=/usr -Qunused-arguments -fstack-protector-strong  -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/mnt/raid10/yocto/master/visionfive2/tmp/work/riscv64-poky-linux/godot/4.3/recipe-sysroot"
export CXX="riscv64-poky-linux-clang++ -target riscv64-poky-linux     -mlittle-endian --dyld-prefix=/usr -Qunused-arguments -fstack-protector-strong  -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/mnt/raid10/yocto/master/visionfive2/tmp/work/riscv64-poky-linux/godot/4.3/recipe-sysroot"
```

### Minimal reproduction project (MRP)

This is solely a build issue
Repository: go
Issue: hash/maphash:purego: TestSmhasherAvalanche failures
Labels: NeedsInvestigation

```
#!watchflakes
default <- pkg == "hash/maphash:purego" && test == "TestSmhasherAvalanche"
```

Issue created automatically to collect these failures.

Example ([log](https://ci.chromium.org/b/8738801229214959937)):

    === RUN   TestSmhasherAvalanche
    === PAUSE TestSmhasherAvalanche
    === CONT  TestSmhasherAvalanche
        smhasher_test.go:360: bad bias for bytes2 bit 1 -> bit 52: 59618/100000
    --- FAIL: TestSmhasherAvalanche (18.52s)


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: deno
Issue: 'deno doc --lint' nondeterministically reports spurious 'private type' errors
Labels: bug,docs

Version: Deno 1.46.2

To reproduce:

```
git clone https://github.com/skybrian/repeat-test
cd repeat-test
git reset --hard c4cb924c9c97230fabea945793ac03fa149545d2
deno doc --lint domain.ts
```

Sometimes it reports no errors, but other times it does. Here's is example output when it reports errors:

```
error[private-type-ref]: public type 'Domain' references private type 'Arbitrary'
  --> /Users/skybrian/Projects/tmp/repeat-test/src/domain_class.ts:48:1
   | 
48 | export class Domain<T> extends Arbitrary<T> {
   | ^
   = hint: make the referenced type public or remove the reference
   | 
33 | export class Arbitrary<T> implements PickSet<T> {
   | - this is the referenced type
   | 

  info: to ensure documentation is complete all types that are exposed in the public API must be public


error[private-type-ref]: public type 'Domain.prototype.regenerate' references private type 'Generated'
   --> /Users/skybrian/Projects/tmp/repeat-test/src/domain_class.ts:122:3
    | 
122 |   regenerate(val: unknown): Generated<T> | Failure {
    |   ^
    = hint: make the referenced type public or remove the reference
    | 
122 | export type Generated<T> = {
    | - this is the referenced type
    | 

  info: to ensure documentation is complete all types that are exposed in the public API must be public


error[private-type-ref]: public type 'Jar.prototype.take' references private type 'PickFunction'
  --> /Users/skybrian/Projects/tmp/repeat-test/src/jar_class.ts:54:3
   | 
54 |   take(pick: PickFunction): T {
   |   ^
   = hint: make the referenced type public or remove the reference
   | 
45 | export interface PickFunction {
   | - this is the referenced type
   | 

  info: to ensure documentation is complete all types that are exposed in the public API must be public


error: Found 3 documentation lint errors.
```
Repository: godot
Issue: Default XR action map broken in webXR on Quest 3
Labels: bug,topic:xr

### Tested versions

Godot v4.3.stable

### System information

Manjaro Linux  X11 - GLES3 (Compatibility) - NVIDIA GeForce RTX 3060 (nvidia; 550.107.02) - Intel(R) Core(TM) i5-8600K CPU @ 3.60GHz (6 Threads)

### Issue description

"primary" action  (for the main thumbstick) is not working. reports 0,0 
godot xr tools movement providers also affected, as they default to this action
other things work, such as the trigger

### Steps to reproduce

create a blank project and add godotxr tools, add the default startxr script to add a button to enter XR mode, add a basic player and controller setup for XR and try adding one of the movement providers (they don't work)

### Minimal reproduction project (MRP)

N/A