ernie-research/MEnvBench huggingface dataset:
Repository: apache/gravitino (Java)

Issue:
[Improvement] Improve the "Default location name" hint message
### What would you like to be improved?

![Image](https://github.com/user-attachments/assets/70e38dfa-eb4a-4029-ae3d-dbc6f7fc227e)

### How should we improve?

I recommend print the accurate property key "default-location-name" in the hint as following:

Default location name must be set and must be one of the fileset locations, location names: [cat, dog], default-location-name: null



Discussion: @mchades Is the api exception message needed to be improved like:` "default-location-name" must be set and must be one of ....` ? Otherwise the user can't know the exact property key from the UI.



Fix (patch):
diff --git a/catalogs/catalog-fileset/src/main/java/org/apache/gravitino/catalog/fileset/FilesetCatalogOperations.java b/catalogs/catalog-fileset/src/main/java/org/apache/gravitino/catalog/fileset/FilesetCatalogOperations.java
index 68297bb7cb3..e5f2a1a10ae 100644
--- a/catalogs/catalog-fileset/src/main/java/org/apache/gravitino/catalog/fileset/FilesetCatalogOperations.java
+++ b/catalogs/catalog-fileset/src/main/java/org/apache/gravitino/catalog/fileset/FilesetCatalogOperations.java
@@ -558,7 +558,9 @@ private Map<String, String> setDefaultLocationIfAbsent(
             && !properties.isEmpty()
             && properties.containsKey(PROPERTY_DEFAULT_LOCATION_NAME)
             && filesetPaths.containsKey(properties.get(PROPERTY_DEFAULT_LOCATION_NAME)),
-        "Default location name must be set and must be one of the fileset locations, "
+        "The fileset property "
+            + PROPERTY_DEFAULT_LOCATION_NAME
+            + " must be set and must be one of the fileset locations, "
             + "location names: "
             + filesetPaths.keySet()
             + ", default location name: "
Repository: LFDT-web3j/web3j (Java)

Issue:
Add @javax.annotation.Generated to generated java classes
## Feature description_
Adding `@Generated` annotation to generated code will help us to, for example, ignore static analysis warning/errors in the generate code.






Fix (patch):
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 85f4a4b36..173131834 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -13,8 +13,10 @@ See [Conventional Commits](https://conventionalcommits.org) for commit guideline
 
 * bump snapshot version to 4.14.1 [#2176](https://github.com/hyperledger-web3j/web3j/pull/2176)
 * add encoding/decoding for EIP-7702 transactions [#2178](https://github.com/LFDT-web3j/web3j/pull/2178)
+* add @javax.annotation.Generated to generated java classes [#2081](https://github.com/LFDT-web3j/web3j/issues/2081)
 * add support for Account Abstraction EIP-4337 transactions [#2187](https://github.com/LFDT-web3j/web3j/pull/2187)
 
+
 ### BREAKING CHANGES
 
 *
diff --git a/codegen/src/main/java/org/web3j/codegen/SolidityFunctionWrapper.java b/codegen/src/main/java/org/web3j/codegen/SolidityFunctionWrapper.java
index d95fb7c9b..babf1e06f 100644
--- a/codegen/src/main/java/org/web3j/codegen/SolidityFunctionWrapper.java
+++ b/codegen/src/main/java/org/web3j/codegen/SolidityFunctionWrapper.java
@@ -247,6 +247,12 @@ public void generateJavaFiles(
                         .addMember("value", "\"rawtypes\"")
                         .build());
 
+        classBuilder.addAnnotation(
+                AnnotationSpec.builder(ClassName.get("javax.annotation.processing", "Generated"))
+                        .addMember(
+                                "value", "$S", "org.web3j.codegen.SolidityFunctionWrapperGenerator")
+                        .build());
+
         classBuilder.addMethod(buildConstructor(Credentials.class, CREDENTIALS, false));
         classBuilder.addMethod(buildConstructor(Credentials.class, CREDENTIALS, true));
         classBuilder.addMethod(
diff --git a/core/src/main/java/org/web3j/protocol/exceptions/TransactionException.java b/core/src/main/java/org/web3j/protocol/exceptions/TransactionException.java
index ca10576fa..b96c4d140 100644
--- a/core/src/main/java/org/web3j/protocol/exceptions/TransactionException.java
+++ b/core/src/main/java/org/web3j/protocol/exceptions/TransactionException.java
@@ -68,7 +68,7 @@ public Optional<String> getTransactionHash() {
     public Optional<TransactionReceipt> getTransactionReceipt() {
         return transactionReceipt;
     }
-    
+
     /**
      * Obtain the Encoded data field from response.
      *
Repository: neoforged/NeoForge (Java)

Issue:
[1.21.8]Animation Loader system is too late to load
Minecraft Version: 1.21.8

NeoForge Version: 21.8.25

Description of issue: after 1.21.6 (or above) mojang change animation system. It cannot use Model.getAnimation in EntityModel class and return to empty animation.
because AnimationLoader is load late after the Entity Model and EntityRenderer load
solusion is should be load before load Entity Model and EntityRenderer
like before in ClientNeoForgeMod.class:
```
    event.addListener(NeoForgeReloadListeners.ENTITY_ANIMATIONS, AnimationLoader.INSTANCE);
```

to this:
```
    event.addDependency(NeoForgeReloadListeners.ENTITY_ANIMATIONS, AnimationLoader.INSTANCE);
```



Fix (patch):
diff --git a/src/client/java/net/neoforged/neoforge/client/ClientNeoForgeMod.java b/src/client/java/net/neoforged/neoforge/client/ClientNeoForgeMod.java
index 0e39663f26d..c1e40c81007 100644
--- a/src/client/java/net/neoforged/neoforge/client/ClientNeoForgeMod.java
+++ b/src/client/java/net/neoforged/neoforge/client/ClientNeoForgeMod.java
@@ -157,7 +157,10 @@ static void onRegisterReloadListeners(AddClientReloadListenersEvent event) {
         event.addDependency(NeoForgeReloadListeners.BRANDING, VanillaClientListeners.FIRST);
 
         event.addListener(NeoForgeReloadListeners.OBJ_LOADER, ObjLoader.INSTANCE);
+
         event.addListener(NeoForgeReloadListeners.ENTITY_ANIMATIONS, AnimationLoader.INSTANCE);
+        // Animations need to be loaded before entity renderers are instantiated
+        event.addDependency(NeoForgeReloadListeners.ENTITY_ANIMATIONS, VanillaClientListeners.ENTITY_RENDERER);
     }
 
     @SubscribeEvent
Repository: neoforged/NeoForge (Java)

Issue:
Oxidization data map doesn't work without extending vanilla's WeatheringCopper{Variant}Block classes.
**Minecraft Version:** 1.21.1 (and up)

**NeoForge Version:** 21.1.143

**Logs:** n/a

**Steps to Reproduce:**
 1. Create a block using the WeatheringCopperFullBlock constructor (properties don't matter)
 2. Add the block to the oxidizables data map
 3. Place block
 4. Wait
 5. Block will not randomtick.

An example of this in the wild is Create.

**Description of issue:**
Or at the very least the docs are wrong as they state using the vanilla class is enough:
https://docs.neoforged.net/docs/resources/server/datamaps/builtin#neoforgeoxidizables
Whether a block is random ticked is cached at registry freeze. WeatheringCopper{Variant}Block checks the map in WeatheringCopper for this (and does not check the isRandomlyTicking block property (that vanilla also doesn't set) so that's not a workaround), when the data map is obviously not loaded yet and so will not contain our new block. Thus without extending the class and overriding isRandomlyTicking, the block won't be ticked.


Discussion: 🚀 This issue has been resolved in NeoForge version `21.5.43-beta`, as part of #2153.



Fix (patch):
diff --git a/src/main/java/net/neoforged/neoforge/common/DataMapHooks.java b/src/main/java/net/neoforged/neoforge/common/DataMapHooks.java
index 5761d1a5565..ef644f34151 100644
--- a/src/main/java/net/neoforged/neoforge/common/DataMapHooks.java
+++ b/src/main/java/net/neoforged/neoforge/common/DataMapHooks.java
@@ -18,6 +18,7 @@
 import net.minecraft.world.level.block.Block;
 import net.minecraft.world.level.block.WeatheringCopper;
 import net.minecraft.world.level.block.entity.FuelValues;
+import net.minecraft.world.level.block.state.BlockState;
 import net.neoforged.bus.api.SubscribeEvent;
 import net.neoforged.neoforge.registries.datamaps.DataMapsUpdatedEvent;
 import net.neoforged.neoforge.registries.datamaps.builtin.NeoForgeDataMaps;
@@ -82,7 +83,15 @@ static void onDataMapsUpdated(DataMapsUpdatedEvent event) {
             INVERSE_WAXABLES_DATAMAP_INTERNAL.clear();
 
             registry.getDataMap(NeoForgeDataMaps.OXIDIZABLES).forEach((resourceKey, oxidizable) -> {
-                INVERSE_OXIDIZABLES_DATAMAP_INTERNAL.put(oxidizable.nextOxidationStage(), BuiltInRegistries.BLOCK.getValue(resourceKey));
+                var block = BuiltInRegistries.BLOCK.getValue(resourceKey);
+
+                INVERSE_OXIDIZABLES_DATAMAP_INTERNAL.put(oxidizable.nextOxidationStage(), block);
+
+                // Rebuild blockstate caches of oxidizables after datamaps are loaded so that they can recompute isRandomlyTicking while having access to the data map value
+                // TODO - revisit this in the future if other datamaps will require rebuilding caches to avoid doing it multiple times
+                for (BlockState state : block.getStateDefinition().getPossibleStates()) {
+                    state.initCache();
+                }
             });
 
             //noinspection deprecation
Repository: langchain4j/langchain4j (Java)

Issue:
Bedrock: GPT-OSS models break because stopSequences is always included (cannot be disabled)
### Description

When using openai.gpt-oss-120b-1:0 on Amazon Bedrock with quarkus-langchain4j-bedrock, the extension always injects stopSequences: [] into the request body.

This causes Bedrock to reject the request:
```
{"message":"This model doesn't support the stopSequences field. Remove stopSequences and try again."}
```

Even if I remove stop-sequences from application.yaml, the extension still serializes it as an empty array due to default parameters.


### Environment
	
- Quarkus: 3.26.2
- quarkus-langchain4j-bedrock: 1.1.3
- AWS Region: us-west-2
- Model: openai.gpt-oss-120b-1:0 (GPT-OSS)


### Steps to Reproduce
1.	Configure application.yaml:
```
quarkus:
  langchain4j:
    bedrock:
      chat-model:
        model-id: openai.gpt-oss-120b-1:0
        aws:
          region: us-west-2
        max-tokens: 512
        temperature: 0.7
```

2.	Register an AI service:
```
@RegisterAiService
@SystemMessage("You are a professional poet")
@ApplicationScoped
public interface PoetAiService {

    @UserMessage("""
                Write a poem about {topic}.
                The poem should be {lines} lines long.
            """)
    String writeAPoem(String topic, int lines);
}
```
3.	Call the service.

4. Observe outgoing JSON request
```
{
  "messages": [...],
  "system": [...],
  "inferenceConfig": {
    "maxTokens": 512,
    "stopSequences": []   <-- always present
  }
}
```

5.	Bedrock returns:
```
{"message":"This model doesn't support the stopSequences field. Remove stopSequences and try again."}
```

### Expected Behaviour
- GPT-OSS models must receive requests without stopSequences.

### Actual Behavior
- stopSequences: [] is always included in the serialized request body, even when not configured.
- This breaks GPT-OSS models, making them unusable via quarkus-langchain4j-bedrock.





Discussion: @yurikotikov thanks a lot for reporting!

cc @geoand the same issue should probably be fixed in Quarkus extension
🙏



Fix (patch):
diff --git a/langchain4j-bedrock/src/main/java/dev/langchain4j/model/bedrock/AbstractBedrockChatModel.java b/langchain4j-bedrock/src/main/java/dev/langchain4j/model/bedrock/AbstractBedrockChatModel.java
index 968e188cca7..3d8208e6d7e 100644
--- a/langchain4j-bedrock/src/main/java/dev/langchain4j/model/bedrock/AbstractBedrockChatModel.java
+++ b/langchain4j-bedrock/src/main/java/dev/langchain4j/model/bedrock/AbstractBedrockChatModel.java
@@ -389,7 +389,7 @@ protected InferenceConfiguration inferenceConfigFrom(ChatRequestParameters param
                 .maxTokens(parameters.maxOutputTokens())
                 .temperature(dblToFloat(parameters.temperature()))
                 .topP(dblToFloat(parameters.topP()))
-                .stopSequences(parameters.stopSequences())
+                .stopSequences(isNullOrEmpty(parameters.stopSequences()) ? null : parameters.stopSequences())
                 .build();
     }
Repository: magefree/mage (Java)

Issue:
BUG - Haunted token creatures dying don't trigger haunt effects
As per title, if a token creature goes to the graveyard (gatherer text: dies) while affected by another card with haunt, the haunt effect doesn't trigger at all. Tried this with both creatures with haunt (belfry spirit, orzhov pontiff, ...) and noncreature spells with haunt (cry of contrition). 

Everything before that is fine: creature with haunt dies/noncreature spell with haunt resolves, haunt trigger lets you select any creature on the battlefield, and the text on the haunted creature reminds of this effect ("haunted by x"). If the haunted creature is not a token and dies, haunt effect successfully goes on the stack and resolves; if it's a token, however, nothing happens.

This is a niche scenario of a probably obscure ability, so I can perfectly understand if this won't be on anyone's radar, like, ever. I thought of bringing it up just in case it's a problem with tokens dying/going to the graveyard bigger problem, but I doubt it.



Fix (patch):
diff --git a/Mage/src/main/java/mage/abilities/keyword/HauntAbility.java b/Mage/src/main/java/mage/abilities/keyword/HauntAbility.java
index 553dfd8847ad..4bd7f4018bc9 100644
--- a/Mage/src/main/java/mage/abilities/keyword/HauntAbility.java
+++ b/Mage/src/main/java/mage/abilities/keyword/HauntAbility.java
@@ -81,8 +81,7 @@ public boolean checkTrigger(GameEvent event, Game game) {
                     return false;
                 }
                 Card card = game.getCard(getSourceId());
-                if (card == null
-                        || game.getCard(event.getTargetId()) == null) {
+                if (card == null) {
                     return false;
                 }
                 String key = new StringBuilder("Haunting_")
Repository: resilience4j/resilience4j (Java)

Issue:
Consider setting Thread.currentThread().interrupted() when InterruptedException thrown in Retry execute*()
Resilience4j version: 2.0.2

Java version: 17

When using Retry.executeSupplier(), if the thread is interrupted while waiting to retry then the state of the current thread is not interrupted so the invoker has no way of knowing that an interrupt exception was thrown. Resilience4j should set `Thread.currentThread().interrupt()` when an `InterruptedException` is thrown instead of swallowing it so downstream code will know the current thread interrupt state.

I checked Reslience4j 1.7.0 and in that case an InterruptedException is thrown (probably because of a sneakythrows) which isn't correct behavior either. I like how 2.0.2 throws the last failed exception. It should just flag the thread as interrupted also.

Here is a test that I think should pass when working correctly.
```
  @Test
  void test() throws Exception {
    var started = new CountDownLatch(1);
    var done = new CountDownLatch(1);
    var error = new AtomicReference<Throwable>();
    var thread =
        new Thread(
            () -> {
              try {
                Retry.of(
                        "retry",
                        RetryConfig.custom()
                            .maxAttempts(3)
                            .waitDuration(Duration.ofSeconds(10))
                            .build())
                    .executeSupplier(
                        () -> {
                          started.countDown();
                          throw new IllegalStateException("Error");
                        });
              } catch (Throwable e) {
                error.set(e);
                done.countDown();
              }
            });
    thread.start();
    assertThat(started.await(1, TimeUnit.SECONDS)).isTrue();
    assertThat(done.await(2, TimeUnit.SECONDS)).isFalse();
    thread.interrupt();
    assertThat(done.await(1, TimeUnit.SECONDS)).isTrue();
    assertThat(error)
        .hasValueSatisfying(e -> assertThat(e).isInstanceOf(IllegalStateException.class));
    assertThat(thread.isInterrupted()).isTrue();
  }
```



Fix (patch):
diff --git a/resilience4j-retry/src/main/java/io/github/resilience4j/retry/internal/RetryImpl.java b/resilience4j-retry/src/main/java/io/github/resilience4j/retry/internal/RetryImpl.java
index 9f1245c23d..3f2f5ab36c 100644
--- a/resilience4j-retry/src/main/java/io/github/resilience4j/retry/internal/RetryImpl.java
+++ b/resilience4j-retry/src/main/java/io/github/resilience4j/retry/internal/RetryImpl.java
@@ -253,6 +253,9 @@ private void waitIntervalAfterException(int currentNumOfAttempts, Either<Throwab
                 () -> new RetryOnRetryEvent(getName(), currentNumOfAttempts, either.swap().getOrNull(), interval));
             try {
                 sleepFunction.accept(interval);
+            } catch (InterruptedException ex) {
+                Thread.currentThread().interrupt();
+                throw lastException.get();
             } catch (Throwable ex) {
                 throw lastException.get();
             }
Repository: apache/paimon (Java)

Issue:
[Bug] Manifest list file name is incorrect
### Search before asking

- [X] I searched in the [issues](https://github.com/apache/incubator-paimon/issues) and found nothing similar.


### Paimon version

0.5-SNAPSHOT

### Compute Engine

Flink

### Minimal reproduce step

Try commit some data and notice the filename of manifest list do not start with `manifest-listxxxx`

![image](https://github.com/apache/incubator-paimon/assets/20527912/3a4a94c4-78b6-4c2b-bbc9-feec5638bd26)


### What doesn't meet your expectations?

 The filename of manifest list should start with `manifest-listxxxx`


### Anything else?

_No response_

### Are you willing to submit a PR?

- [X] I'm willing to submit a PR!



Fix (patch):
diff --git a/paimon-core/src/main/java/org/apache/paimon/manifest/ManifestList.java b/paimon-core/src/main/java/org/apache/paimon/manifest/ManifestList.java
index c115367134de..34ebe330870a 100644
--- a/paimon-core/src/main/java/org/apache/paimon/manifest/ManifestList.java
+++ b/paimon-core/src/main/java/org/apache/paimon/manifest/ManifestList.java
@@ -110,7 +110,7 @@ public ManifestList create() {
                     new ManifestFileMetaSerializer(),
                     fileFormat.createReaderFactory(metaType),
                     fileFormat.createWriterFactory(metaType),
-                    pathFactory.manifestFileFactory(),
+                    pathFactory.manifestListFactory(),
                     cache);
         }
     }
Repository: apache/paimon (Java)

Issue:
[Bug] Paimon throws an exception "cannot be cast to float due to precision loss" when the float data has five decimal places or more.
### Search before asking

- [x] I searched in the [issues](https://github.com/apache/paimon/issues) and found nothing similar.


### Paimon version

paimon-1.0

### Compute Engine

Flink 1.17

### Minimal reproduce step

Insert any floating-point data with five or more decimal places into the Paimon table.

### What doesn't meet your expectations?

Thers is the code that cast string to float。 In fact, when a number has four decimal places, converting a float type to a String type will result in scientific notation. In this case, directly comparing their string lengths is meaningless. However, when the number has exactly four decimal places, the lengths happen to be the same (e.g. len(0.0001) = len(2.0E-4)). so when there are exactly faive decimal places, which will throw the exception.
```
case FLOAT:
                double d = Double.parseDouble(s);
                if (d == ((float) d)) {
                    return (float) d;
                } else {
                    // Compatible canal-cdc
                    Float f = Float.valueOf(s);
                    if (f.toString().length() != s.length()) {
                        throw new NumberFormatException(
                                s + " cannot be cast to float due to precision loss");
                    } else {
                        return f;
                    }
                }
```

![Image](https://github.com/user-attachments/assets/4e9abe1a-00f1-4594-a1c8-9a4806ba9e56)

<img width="812" alt="Image" src="https://github.com/user-attachments/assets/c5283d2d-a847-44c8-8012-1dbec2ba0bd2" />

org.apache.paimon.utils.TypeUtils#castFromStringInternal() 




### Anything else?

_No response_

### Are you willing to submit a PR?

- [x] I'm willing to submit a PR!



Fix (patch):
diff --git a/paimon-common/src/main/java/org/apache/paimon/utils/TypeUtils.java b/paimon-common/src/main/java/org/apache/paimon/utils/TypeUtils.java
index 4f96909ceb13..7b6d030104d2 100644
--- a/paimon-common/src/main/java/org/apache/paimon/utils/TypeUtils.java
+++ b/paimon-common/src/main/java/org/apache/paimon/utils/TypeUtils.java
@@ -144,7 +144,12 @@ public static Object castFromStringInternal(String s, DataType type, boolean isC
                 } else {
                     // Compatible canal-cdc
                     Float f = Float.valueOf(s);
-                    if (f.toString().length() != s.length()) {
+                    String floatStr = f.toString();
+                    if (s.contains(".") && !s.contains("E")) {
+                        int decimal = s.length() - s.indexOf(".") - 1;
+                        floatStr = String.format("%." + decimal + "f", f);
+                    }
+                    if (!floatStr.equals(s)) {
                         throw new NumberFormatException(
                                 s + " cannot be cast to float due to precision loss");
                     } else {
Repository: FabricMC/fabric (Java)

Issue:
ServerLoginNetworking.registerReceiver from fabric-networking-api-v1 does not work
Registering a channel using `ServerLoginNetworking.registerReceiver` does not work. The vanilla response of kicking the client when the server receives the client's query response packet is triggered instead of `LoginQueryResponseHandler.receive`.

The global counterpart `ServerLoginNetworking.registerGlobalReceiver` works fine.

I've made a demo mod here: https://github.com/DiffuseHyperion/TestingLoginQuery. Attempting to join the modded server should see you getting kicked with the message "Unexpected custom data from client", instead of being able to join the server normally.



Fix (patch):
diff --git a/fabric-networking-api-v1/src/main/java/net/fabricmc/fabric/impl/networking/server/ServerLoginNetworkAddon.java b/fabric-networking-api-v1/src/main/java/net/fabricmc/fabric/impl/networking/server/ServerLoginNetworkAddon.java
index 957a56d7a7..2aca466e09 100644
--- a/fabric-networking-api-v1/src/main/java/net/fabricmc/fabric/impl/networking/server/ServerLoginNetworkAddon.java
+++ b/fabric-networking-api-v1/src/main/java/net/fabricmc/fabric/impl/networking/server/ServerLoginNetworkAddon.java
@@ -147,7 +147,7 @@ private boolean handle(int queryId, @Nullable PacketByteBuf originalBuf) {
 		}
 
 		boolean understood = originalBuf != null;
-		@Nullable ServerLoginNetworking.LoginQueryResponseHandler handler = ServerNetworkingImpl.LOGIN.getHandler(channel);
+		@Nullable ServerLoginNetworking.LoginQueryResponseHandler handler = this.getHandler(channel);
 
 		if (handler == null) {
 			return false;