Master CI failing since `810fe5d`: `1.6.13-SNAPSHOT` WALA artifacts unresolvable

[khatchad]

Summary

master's build job has been failing since 810fe5d (the bump of org.codehaus.mojo:exec-maven-plugin from 3.5.1 to 3.6.1, #336). The failure is environmental, not caused by the bump itself — the cause is dependency-resolution failure for com.ibm.wala:*:1.6.13-SNAPSHOT artifacts.

Failure Mode

[ERROR] Could not find artifact com.ibm.wala:com.ibm.wala.util:jar:1.6.13-SNAPSHOT
[ERROR] dependency: com.ibm.wala:com.ibm.wala.shrike:jar:1.6.13-SNAPSHOT (compile)
[ERROR] dependency: com.ibm.wala:com.ibm.wala.core:jar:1.6.13-SNAPSHOT (compile)
[ERROR] dependency: com.ibm.wala:com.ibm.wala.cast:jar:1.6.13-SNAPSHOT (compile)
[ERROR] dependency: com.ibm.wala:com.ibm.wala.cast.java:jar:1.6.13-SNAPSHOT (compile)

CI can't resolve the WALA SNAPSHOT artifacts. There's no accessible Maven repository serving them from this CI's perspective.

Timeline (Build Job per Commit)

SHA	Status	Description
2dc3cb2	green	Bump wala.version from 1.6.12-SNAPSHOT to 1.6.12 (#324) — last stable-version commit
386a846	green	"Use WALA SNAPSHOT version, upgrade to Java 25, ..." (#326) — switched back to 1.6.13-SNAPSHOT
35fb90b	green	Add Copilot instructions (#330)
ef22e49	green	Remove duplicated build configurations (#328)
55304c2	green	Bump jacoco-maven-plugin (#337)
fba6551	green	Bump spotless-maven-plugin to 3.0.0 (#335)
810fe5d	failure (19 retries)	Bump exec-maven-plugin to 3.6.1 (#336)

Diagnosis

The SNAPSHOT switch in 386a846 introduced the latent fragility, but did not itself break the build — that commit and the next four built green, demonstrating the snapshots WERE resolvable at that time. The transition to red happened at 810fe5d, but the bump there is unrelated to dependency resolution. Most likely:

• The WALA SNAPSHOT artifacts were rotated out / replaced / lost (typical Maven snapshot retention behavior), and earlier CI builds happened to hit the cache window where they were still resolvable.
• Or the snapshot repo URL/auth changed and only fresh resolution attempts surface the failure.
• Either way, 810fe5d is the surfacing point, not the cause.

Suggested Fixes

Two complementary directions:

1. Pin to a stable WALA release — 2dc3cb2 previously switched 1.6.12-SNAPSHOT → 1.6.12 for exactly this fragility reason. The same logic suggests reverting the SNAPSHOT switch in 386a846 once 1.6.13 is published. If 1.6.13 isn't out yet, either pin to 1.6.12 again (with documented Java-version implications), or wait for the release.
2. Add a snapshot repository to pom.xml's <repositories> section explicitly, pointing at a known-permanent location for WALA snapshots (e.g., Sonatype OSSRH snapshots repo if WALA publishes there). Documents the dependency on snapshot infrastructure and makes resolution reproducible.

Impact

Master is unbuildable on CI. Open PRs (e.g., #432) inherit the failure regardless of their content, so they can't pass checks until master is restored. Automerge can't fire on those PRs.

Related

• Bump org.codehaus.mojo:exec-maven-plugin from 3.5.1 to 3.6.1 #336 — the exec-maven-plugin bump where the failure first surfaced (effect, not cause).
• Use WALA SNAPSHOT version, upgrade to Java 25, and upgrade the Google Java Format for Java 25 #326 — the SNAPSHOT switch that introduced the latent fragility.
• Bump wala.version from 1.6.12-SNAPSHOT to 1.6.12 #324 — earlier transition AWAY from SNAPSHOT (1.6.12-SNAPSHOT → 1.6.12); same fragility motivated that.
• Use ${maven.multiModuleProjectDirectory}/spotless.xml.prefs for robust resolution #432 — currently-open PR blocked by this issue.

[khatchad]

Tried Pinning To A Released WALA — Doesn't Work

Quick experiment off upstream/master to test the hypothesis that pinning to a released WALA version (instead of 1.6.13-SNAPSHOT) would unblock CI:

• Latest WALA release on Maven Central: 1.6.10 (April 2025). There is no released 1.6.11, 1.6.12, or 1.6.13.

• Tried: <wala.version>1.6.13-SNAPSHOT</wala.version> → <wala.version>1.6.10</wala.version>, mvn -pl ml/com.ibm.wala.cast.python.ml -am compile.

• Result: compile failure — wala/ML uses newer-than-1.6.10 WALA APIs:

  [ERROR] PythonSSAPropagationCallGraphBuilder.java:[834,9] cannot find symbol
    symbol:   method newFieldOperation(CGNode, int, int, boolean,
                  PythonConstraintVisitor.TrampolineWriter)
  [ERROR] PythonScopeMappingInstanceKeys.java:[57,3]
    method does not override or implement a method from a supertype
  

So the SNAPSHOT presence is intentional — wala/ML legitimately requires WALA APIs added after 1.6.10 (the trampoline-writer overload, plus the scope-mapping override-target). The fix shape isn't "bump to a release"; it's one of:

1. Cut a WALA 1.6.11 (or higher) release that includes those APIs, then pin wala/ML to it.
2. Fix the SNAPSHOT publication pipeline so 1.6.13-SNAPSHOT resolves reliably from CI (the actual root cause of Master CI failing since 810fe5d: 1.6.13-SNAPSHOT WALA artifacts unresolvable #433's symptoms — see 810fe5d5 timing).
3. Vendor the needed WALA changes into wala/ML's own classpath until upstream WALA cuts a release. (Heaviest option.)

(1) is cleanest if WALA's release cadence cooperates; (2) is the right long-term fix for SNAPSHOT consumers in general.

[khatchad]

Update: 1.7.1 And 1.6.12 Both Tried, Both Insufficient

Followed up on the released-WALA hypothesis with each of the post-1.6.10 releases (v1.6.11, v1.6.12, v1.7.0, v1.7.1 per the WALA release page). Two distinct API-break boundaries straddle wala/ML:

WALA 1.7.x (latest, including 1.7.1) — Compile Failure

AstTranslator interface changes:

[ERROR] PythonLoader.java:[384] incompatible types:
   Map<IBasicBlock, TypeReference[]>  vs.  Map<IBasicBlock, Set<TypeReference>>
[ERROR] PythonCAstToIRTranslator.java:[83] is not abstract and does not override
   doFieldWrite(WalkContext, int, CAstNode, CAstNode, CAstNode, int)
[ERROR] PythonCAstToIRTranslator.java:[200,298,336] method does not override or implement
   a method from a supertype

Adopting 1.7.x would require porting wala/ML to the new AstTranslator API surface (defineFunction signature, doFieldWrite override, etc.) — a real refactor, not a version bump.

WALA 1.6.12 (last 1.6.x release) — Compile Clean, 72 Runtime Failures

mvn -pl ml/com.ibm.wala.cast.python.ml.test -am test against <wala.version>1.6.12</wala.version>:

• Builds cleanly.
• TestTensorflow2Model runs 353 tests (vs. 590 under 1.6.13-SNAPSHOT) with 72 failures.
• All 72 failures share the pattern AssertionError: Function script ... must exist in call graph — i.e., the call graph isn't picking up entrypoint methods that wala/ML's tests assume are present.
• This points at entrypoint/scope-mapping work that landed in WALA between 1.6.12 and 1.7.0 — exactly the contents of 1.6.13-SNAPSHOT.

Implication

1.6.13-SNAPSHOT isn't a stale pin to be bumped — it's the only WALA tip on which wala/ML's current code works correctly:

• 1.6.10/11/12: missing the entrypoint additions wala/ML's tests depend on.
• 1.7.x: the AstTranslator was refactored away from wala/ML's expectations.

So the path to unblocking CI isn't a version bump. The remaining options are:

1. Get WALA to cut a 1.6.13 release (or any tagged release containing the SNAPSHOT's contents) and pin to that. Cleanest if WALA's release cadence cooperates.
2. Pin to a dated SNAPSHOT artifact (e.g. 1.6.13-20250730.123456-N) instead of the moving -SNAPSHOT tag. Avoids the "current SNAPSHOT failed to publish" race.
3. Fix the SNAPSHOT publication pipeline so 1.6.13-SNAPSHOT resolves reliably from CI. Right long-term fix.
4. Vendor the needed WALA changes into wala/ML's classpath. Heaviest.

(2) is probably the fastest unblock, (1) the cleanest. Either way, the user-suggested "use a released version" doesn't directly work without one of the above.

[khatchad]

Cross-Refs Filed

For tracking continuity:

• wala/WALA#1895 — request to document the AstTranslator API breaks between 1.6.12 and 1.7.0. Relevant if anyone tries the medium-term "port to 1.7.x" option from my comment above.
• wala/ML#440 — durable resolution tracker tying this issue to the in-flight JEP migration. JEP completion makes the SNAPSHOT pin obsolete; until then, the dated-SNAPSHOT pin is the simplest mitigation.

[khatchad]

Corrected Diagnosis: It's A Submodule-Tracking Choice, Not An Artifact-Resolution Race

Spent some more time tracing this end-to-end and the actual root cause is much simpler than anything in my previous comments. No remote 1.6.13-SNAPSHOT artifact exists — Sonatype Central snapshots returns 404, OSS Sonatype returns nothing, Maven Central has only released 1.6.x and 1.7.x tags. The 1.6.13-SNAPSHOT jars in local ~/.m2/ caches all have <localCopy>true</localCopy> in their maven-metadata-local.xml, meaning they're built locally, not fetched.

How does CI ever resolve 1.6.13-SNAPSHOT then? It builds WALA from source via the submodule:

- name: Check out wala/ML sources
  uses: actions/checkout@v5
  with:
    submodules: 'recursive'
- name: Update the WALA submodule with its latest commit
  run: git submodule update --recursive --remote      # ← this is the issue
- …
- name: Install WALA.
  run: |
    pushd WALA
    ./gradlew build publishToMavenLocal -x test -x javadoc -x lintMarkdown
    popd

The --remote flag overrides the committed submodule pointer with whatever's at wala/WALA:master HEAD. So 1.6.13-SNAPSHOT isn't a frozen artifact — it's "whatever WALA master happens to produce right now."

What Broke

The committed submodule pointer in wala/ML:master is c0e260a62b9faa523bd907a747f9b83b90f090da ("Prepare next development version", 2025-09-22). That commit precedes WALA's f08697550 ("Record catch types as Set, not array (#1803)", 2025-12-12) by three months, and so is API-compatible with wala/ML's code.

The --remote flag was added in PR #305 (2025-09-06) to "ensure the WALA submodule is always updated to its latest commit." That intent — bleeding-edge WALA tracking — is what causes CI to pull commits that have moved past wala/ML's compatibility cliff.

The Real Fix

Drop the --remote flag. Use the committed submodule pointer (c0e260a62). CI becomes deterministic and resolves to a known-good WALA tip. New WALA changes are picked up only when someone intentionally bumps the submodule pointer in a PR.

Concretely, change the CI step from:

- name: Update the WALA submodule with its latest commit
  run: git submodule update --recursive --remote

to either:

- name: Update the WALA submodule
  run: git submodule update --init --recursive

(or just delete the step entirely — actions/checkout with submodules: 'recursive' already initializes them at the committed pointer).

What This Means For The Other Issues

• #440 (JEP migration tracker) — the JEP migration is still the durable answer for #436 (Jython-init NPE) and for de-coupling from Jython's JDK-version-compat issues. But it's no longer required to unblock CI; the submodule pointer-pin is sufficient for CI.
• #441 (extending JEP to ml/) — still valid as architectural work; not a CI blocker anymore.
• #442 (dated-SNAPSHOT pin recipe) — not actually viable, since no remote SNAPSHOT artifacts exist. I'll close that issue with a redirect to this comment.
• wala/WALA#1895 (document AstTranslator API breaks) — still useful for whoever eventually moves wala/ML's WALA pin forward through the 1.7.x line.

Suggested Action

A one-line CI workflow PR. Once landed, #433 closes. The harder questions (when to bump the pin, how to absorb the 1.7.x AstTranslator changes when ready, how to schedule the JEP migration) become deliberate downstream work rather than CI-fire-fighting.

[khatchad]

Filed wala/WALA#1896 as the surgical release ask: tag 4eb96214e (parent of the AstTranslator break) as v1.6.13. That gives wala/ML a released WALA coordinate to pin to and unblocks Maven-releasability — separate from but complementary to the CI workflow fix in the corrected diagnosis above.

[khatchad]

Update: v1.6.13 Released On Maven Central

wala/WALA#1896 was accepted by @msridhar — v1.6.13 is tagged at the SHA we asked for and is on Maven Central. This unblocks a more durable fix than the CI workflow change in #443.

New Path Forward

A single PR could:

1. Bump <wala.version>1.6.13-SNAPSHOT</wala.version> → <wala.version>1.6.13</wala.version> in pom.xml.
2. Port test files from Object[][] → List<TestCallGraphShape.GraphAssertion>. WALA commit e8a85c8aa (#1740) flipped that signature, and the change is in 1.6.13 (predates the requested SHA, separate from the AstTranslator break that wasn't in). About 78 mechanical sites across 11 Test*.java files — a sed/python script handles it.
3. Remove the WALA submodule entirely (matches the long-term goal in #440). The ./gradlew build publishToMavenLocal step exists specifically to fill the SNAPSHOT gap; with a released coordinate available, it's no longer needed.
4. Simplify CI — drop the submodule-update step (closes #443 as a side effect) and the ./gradlew install step.

Status Of Related Work

• #443 (workflow --remote drop) — still valid as an immediate unblock if the bigger bump-and-cleanup PR doesn't land first. Could close in favor of the consolidation, or merge as a stop-gap.
• #440 (JEP migration tracker) — the 1.6.13 release doesn't change the long-term JEP migration plan, but it removes the immediate Jython-coupling pressure.
• wala/WALA#1895 (document AstTranslator API breaks) — still useful for whoever eventually moves wala/ML's pin past 1.6.13 to the 1.7.x line.