[build] update java graphpql dependency by filtering out bad reference

[titusfortner]

💥 What does this PR do?

graphql did a weirdly formatted release on maven that will always show up as the "latest" even though it is not, and there's nothing anyone can do about it. Instead of hard coding a version, this is falling back to filtering out results from maven directly. It only applies to graphql.

Also got a bunch of other updates when I ran ./go java:update so those are here too

🔧 Implementation Notes

Only alternative is hard coding the value

🤖 AI assistance

• No substantial AI assistance used
• AI assisted (complete below)
  • Tool(s): codex
  • What was generated: maven_stable_release()
  • I reviewed all AI output and can explain the change

💡 Additional Considerations

🔄 Types of changes

• Bug fix (backwards compatible)

[qodo-code-review]

Review Summary by Qodo

🐞 Bug fix ✨ Enhancement

Walkthroughs

Description

• Filter out non-stable GraphQL Maven artifacts to prevent version resolution issues
• Implement maven_stable_release() function to fetch stable versions from Maven Central
• Update multiple Java dependencies including GraphQL, SLF4J, Lettuce, and Kubernetes client
  libraries
• Update generated Maven metadata and dependency checksums

Diagram

flowchart LR
  A["Maven Outdated Check"] --> B["Detect Non-Stable GraphQL"]
  B --> C["Query Maven Central XML"]
  C --> D["Extract Stable Versions"]
  D --> E["Update MODULE.bazel"]
  E --> F["Regenerate maven_install.json"]

Loading

File Changes

1. rake_tasks/java.rake 🐞 Bug fix +20/-3

Add stable release filtering for GraphQL dependency

• Added maven_stable_release() function to query Maven Central XML metadata for stable releases
• Enhanced GraphQL dependency filtering to detect non-stable date-based artifacts (e.g., YYYYMMDD-
 format)
• Falls back to Maven Central lookup instead of skipping GraphQL updates when non-stable versions
 are detected
• Improved error handling with warning messages for failed Maven queries

rake_tasks/java.rake

---

2. MODULE.bazel Dependencies +4/-4

Update Java dependency versions in MODULE.bazel

• Updated com.graphql-java:graphql-java from 24.1 to 26.0
• Updated io.lettuce:lettuce-core from 7.5.1.RELEASE to 7.5.2.RELEASE
• Updated org.slf4j:slf4j-api from 2.0.17 to 2.0.18
• Updated org.slf4j:slf4j-jdk14 from 2.0.17 to 2.0.18

MODULE.bazel

---

3. java/maven_install.json Dependencies +62/-63

Update Maven dependency checksums and metadata

• Updated checksums and version metadata for GraphQL Java (24.1 → 26.0) and java-dataloader (5.0.0 →
 6.0.0)
• Updated checksums for SLF4J libraries (2.0.17 → 2.0.18)
• Updated checksums for Lettuce Core (7.5.1.RELEASE → 7.5.2.RELEASE)
• Updated checksums for multiple Kubernetes client and Fabric8 model dependencies
• Removed graphql.agent.result package from GraphQL Java exports; added
 graphql.util.querygenerator package

java/maven_install.json

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (1) 📎 Requirement gaps (0)

1. Unvalidated Maven HTTP response 🐞 Bug ☼ Reliability

Description

maven_stable_release reads http.get(...).body without checking the HTTP status, so
redirects/errors (3xx/4xx/5xx) are treated as XML metadata and then parsed. This can cause graphql
updates to be skipped (parse error -> rescued) or produce incorrect behavior when Maven Central
returns non-metadata content.

Code

rake_tasks/java.rake[R315-316]

+  xml = Net::HTTP.start(uri.host, uri.port, use_ssl: true, open_timeout: 5, read_timeout: 10) do |http|
+    http.get(uri.request_uri).body

Evidence

The new code fetches the response body directly (no status validation). Elsewhere in the same rake
file, an HTTP call explicitly checks for Net::HTTPSuccess and fails fast on non-2xx responses,
showing the expected handling pattern in this codebase.

rake_tasks/java.rake[314-317]
rake_tasks/java.rake[111-127]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`maven_stable_release` fetches `maven-metadata.xml` and immediately uses the response body as XML without checking whether the HTTP request succeeded.

## Issue Context
Non-2xx responses (redirects, rate limits, 404/500) can return HTML or other non-XML content; the function then attempts to parse it as XML and relies on the broad rescue, which results in a warning + `nil` and skips updates.

## Fix Focus Areas
- rake_tasks/java.rake[315-317]

## Suggested change
- Capture the full response object.
- Verify `response.is_a?(Net::HTTPSuccess)` (and optionally follow redirects) before reading/parsing the body.
- Include status code/body snippet in the warning/error path for easier diagnosis.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. maven_stable_release swallows all errors 📘 Rule violation ☼ Reliability

Description

maven_stable_release rescues StandardError and returns nil, which can hide network/parsing
failures and lead to non-deterministic or silently incomplete dependency updates. This violates the
requirement that build/CI/scripts avoid blanket error-swallowing that hides failures.

Code

rake_tasks/java.rake[R320-323]

+rescue StandardError => e
+  puts "WARNING — Failed to fetch stable release for #{artifact}: #{e.message}"
+  nil
+end

Evidence

PR Compliance ID 11 forbids blanket error-swallowing in scripts. The added `rescue StandardError =>
e block logs a warning and returns nil`, allowing the update workflow to continue without
deterministically failing when Maven metadata fetch/parsing fails.

rake_tasks/java.rake[310-323]
Best Practice: Learned patterns

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`maven_stable_release` uses `rescue StandardError` and returns `nil`, which swallows failures and can cause the `java:update` task to proceed with incomplete/incorrect updates.

## Issue Context
Compliance requires build/CI/scripts to avoid blanket error-swallowing and to behave deterministically.

## Fix Focus Areas
- rake_tasks/java.rake[310-323]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. No HTTP timeouts ✓ Resolved 🐞 Bug ☼ Reliability

Description

maven_stable_release uses Net::HTTP.get without open/read timeouts, so rake java:update can hang
indefinitely on network stalls. This makes dependency updates flaky and can block CI/developer
workflows.

Code

rake_tasks/java.rake[R310-323]

+def maven_stable_release(artifact)
+  require 'rexml/document'
+  group_id, artifact_id = artifact.split(':', 2)
+  group_path = group_id.tr('.', '/')
+  url = "https://repo1.maven.org/maven2/#{group_path}/#{artifact_id}/maven-metadata.xml"
+  xml = Net::HTTP.get(URI(url))
+  doc = REXML::Document.new(xml)
+  versions = doc.elements.to_a('metadata/versioning/versions/version').map(&:text)
+  stable = versions.grep(/\A\d+\.\d+(\.\d+)*\z/)
+  stable.max_by { |v| Gem::Version.new(v) }
+rescue StandardError => e
+  puts "WARNING — Failed to fetch stable release for #{artifact}: #{e.message}"
+  nil
+end

Evidence

The new helper calls Net::HTTP.get with no timeout configuration, while the same file’s Sonatype
upload HTTP call explicitly sets open_timeout and read_timeout, showing the repo expects bounded
network calls.

rake_tasks/java.rake[310-323]
rake_tasks/java.rake[101-114]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`maven_stable_release` fetches `maven-metadata.xml` via `Net::HTTP.get` without any timeouts, which can cause `rake java:update` to hang indefinitely if Maven Central is slow or the connection stalls.

### Issue Context
This rake file already uses `Net::HTTP.start` with explicit `open_timeout` and `read_timeout` for other HTTP calls, so timeouts are an established reliability pattern here.

### Fix Focus Areas
- rake_tasks/java.rake[310-323]
- rake_tasks/java.rake[101-114]

### Suggested fix
Replace `Net::HTTP.get(URI(url))` with a `Net::HTTP.start` call that sets `use_ssl: true` plus `open_timeout` / `read_timeout`, and read the response body via `Net::HTTP::Get` so the call fails fast instead of hanging.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

4. Brittle graphql version gate 🐞 Bug ≡ Correctness

Description

The graphql fallback is only triggered when the outdated version matches /\A(\d{6}-|0\.0\.0-)/, so
other non-stable formats will still be written into MODULE.bazel. This undermines the stated goal of
filtering out Maven’s non-stable “latest” versions for graphql.

Code

rake_tasks/java.rake[R295-302]

+    if artifact.match?('graphql') && version.match?(/\A(\d{6}-|0\.0\.0-)/)
+      # Maven Central indexes non-stable date-based artifacts that sort as "latest" which breaks for graphql
      # https://github.com/graphql-java/graphql-java/discussions/3187
-      puts 'WARNING — Cannot automatically update graphql'
-      next
+      # Fall back to calling maven directly for this
+      version = maven_stable_release(artifact)
+      next if version.nil?
    end
    content.sub!(/#{Regexp.escape(artifact)}:([\d.-]+(?:[-.]?[A-Za-z0-9]+)*)/, "#{artifact}:#{version}")

Evidence

The update loop only calls the Maven metadata fallback for two specific prefixes, even though the
helper itself defines stable versions via a numeric-dot filter. This mismatch means non-stable
versions outside those prefixes will bypass the fallback entirely.

rake_tasks/java.rake[293-303]
rake_tasks/java.rake[317-320]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The fallback to `maven_stable_release` is gated by a narrow regex (`\A(\d{6}-|0\.0\.0-)`) that only catches two specific unstable version prefixes. Any other non-stable version format returned by `@maven//:outdated` will bypass the fallback and be substituted into `MODULE.bazel`.

### Issue Context
`maven_stable_release` already defines what “stable” means by filtering versions to a numeric-dot format before selecting the max version. The gate in the update loop should align with that same stability criterion instead of maintaining a small list of “bad” prefixes.

### Fix Focus Areas
- rake_tasks/java.rake[293-303]
- rake_tasks/java.rake[317-320]

### Suggested fix
In the update loop, replace the current `version.match?(/\A(\d{6}-|0\.0\.0-)/)` check with a stability check (e.g., `stable_re = /\A\d+(?:\.\d+)*\z/` or whatever you consider stable), and call `maven_stable_release` when the proposed version does *not* match that stable pattern.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[qodo-code-review]

Persistent review updated to latest commit 15b983a