stanfordnlp/CoreNLP · error · RuntimeException

check flag in markMentionRelation…

Error message

check flag in markMentionRelation (dcoref/MentionExtractor.java)

What it means

markMentionRelation (now in DocumentPreprocessor) throws when an unrecognized relation flag string reaches it. The flag set (APPOS, PREDICATE_NOMINATIVE, RELATIVE_PRONOUN, etc.) is internal; receiving an unknown value is an internal invariant violation indicating version drift between code that emits flags and code that consumes them.

Solutions

  1. Ensure a single consistent CoreNLP version on the classpath (mvn dependency:tree; remove old jars)
  2. Clean rebuild to eliminate stale compiled classes mixing old and new relation flags
  3. Do not patch markMentionRelation flag generation without updating the corresponding case list
  4. Upgrade the whole CoreNLP dependency rather than individual coref classes
Defensive patterns

Strategy: validation

Validate before calling

// Detect duplicate CoreNLP versions on the classpath
Enumeration<URL> res = ClassLoader.getSystemResources("edu/stanford/nlp/coref/data/DocumentPreprocessor.class");
if (res.hasMoreElements() && res.nextElement() != null && res.hasMoreElements())
  throw new IllegalStateException("Multiple CoreNLP classes found on classpath");

Try / catch

try {
  new DocumentPreprocessor();
} catch (RuntimeException e) {
  if (e.getMessage() != null && e.getMessage().startsWith("check flag in markMentionRelation")) {
    logger.severe("Version drift: unknown relation flag; check classpath for mixed CoreNLP jars");
  } else throw e;
}

Prevention

When it happens

Trigger: DocumentPreprocessor construction invoking markMentionRelation where flag equals none of the enumerated values — caused by mixing classes from different CoreNLP versions or a modified enumeration of relation flags.

Common situations: Classpath containing two CoreNLP jar versions (e.g. a shaded/older dcoref MentionExtractor with new flags or vice versa); custom forks patched on one side only; OSGi/shading issues pulling stale classes.

Understand the failure class

Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.

Related errors


AI-assisted analysis of stanfordnlp/CoreNLP@1b7edd19c4 (2026-09-10). Data as JSON: /api/errors/71dc08d40f3a8d6e. Report an issue: GitHub.

Appendix: source

Thrown at src/edu/stanford/nlp/coref/data/DocumentPreprocessor.java:929

      for(Mention m2 : orderedMentions){
        if(m1==m2) continue;
        // Ignore if m2 and m1 are in list relationship
        if (m1.isListMemberOf(m2) || m2.isListMemberOf(m1) || m1.isMemberOfSameList(m2)) {
          //Redwood.log("debug-preprocessor", "Not checking '" + m1 + "' and '" + m2 + "' for " + flag + ": in list relationship");
          continue;
        }
        for(Pair<Integer, Integer> foundPair: foundPairs){
          if (foundPair.first() == m1.headIndex && foundPair.second() == m2.headIndex) {
            if(flag.equals("APPOSITION")) {
              if ( ! foundPair.first().equals(foundPair.second()) || m2.insideIn(m1)) {
                m2.addApposition(m1);
              }
            }
            else if(flag.equals("PREDICATE_NOMINATIVE")) {
              m2.addPredicateNominatives(m1);
            }
            else if(flag.equals("RELATIVE_PRONOUN")) m2.addRelativePronoun(m1);
            else throw new RuntimeException("check flag in markMentionRelation (dcoref/MentionExtractor.java)");
          }
        }
      }
    }
  }

//  private static final TregexPattern relativePronounPattern = TregexPattern.compile("NP < (NP=m1 $.. (SBAR < (WHNP < WP|WDT=m2)))");
//  private static void findRelativePronouns(Tree tree, Set<Pair<Integer, Integer>> relativePronounPairs) {
//    findTreePattern(tree, relativePronounPattern, relativePronounPairs);
//  }
}

View on GitHub (pinned to 1b7edd19c4)