bumptech/glide · error · IllegalStateException

Cannot process annotations after writing AppGlideModule

Error message

Cannot process annotations after writing AppGlideModule

What it means

GlideAnnotationProcessor writes the combined GeneratedAppGlideModule only once (tracked by isGeneratedAppGlideModuleWritten) and treats that as a point of no return. If, in a later annotation-processing round, a new LibraryGlideModule or GlideExtension is discovered (newModulesWritten || newExtensionWritten) after the app module was already written, the processor throws rather than emit inconsistent/missing indexer entries. It is an internal ordering invariant violation, not a normal user-annotation mistake.

Source

Thrown at annotation/compiler/src/main/java/com/bumptech/glide/annotation/compiler/GlideAnnotationProcessor.java:130

   *   <li>Find all {@code LibraryGlideModule}s
   *   <li>For each {@code LibraryGlideModule}, write an {@code Indexer} with an Annotation with the
   *       class name.
   *   <li>If we wrote any {@code Indexer}s, return and wait for the next round.
   *   <li>If we didn't write any {@code Indexer}s and there is a {@code AppGlideModule}, write the
   *       {@code GeneratedAppGlideModule}. Once the {@code GeneratedAppGlideModule} is written, we
   *       expect to be finished. Any further generation of related classes will result in errors.
   * </ol>
   */
  @Override
  public boolean process(Set<? extends TypeElement> set, RoundEnvironment env) {
    processorUtil.process();
    boolean newModulesWritten = libraryModuleProcessor.processModules(env);
    boolean newExtensionWritten = extensionProcessor.processExtensions(env);
    appModuleProcessor.processModules(set, env);

    if (newExtensionWritten || newModulesWritten) {
      if (isGeneratedAppGlideModuleWritten) {
        throw new IllegalStateException("Cannot process annotations after writing AppGlideModule");
      }
      return false;
    }

    if (!isGeneratedAppGlideModuleWritten) {
      isGeneratedAppGlideModuleWritten = appModuleProcessor.maybeWriteAppModule();
    }
    return false;
  }
}

View on GitHub (pinned to eb14a895d8)

Solutions

1. Clean and rebuild (`./gradlew clean` then build) to rule out stale/incremental state.
2. Ensure no other annotation processor generates classes annotated with @GlideModule or @GlideExtension.
3. Disable incremental compilation for the affected module (kapt.use.worker.api=false / kapt.incremental.apt=false) to confirm whether round ordering is the cause, then isolate the offending processor.
4. Upgrade glide:compiler and kotlin/kapt versions — round-ordering bugs are usually fixed upstream.
5. Move hand-written @GlideModule/@GlideExtension classes so they are visible in the first processing round (same module, no generated indirection).

When it happens

Trigger: GlideAnnotationProcessor.process: after libraryModuleProcessor.processModules / extensionProcessor.processExtensions return true in a round following the one where isGeneratedAppGlideModuleWritten became true, the guard `if (newExtensionWritten || newModulesWritten) { if (isGeneratedAppGlideModuleWritten) throw }` fires. Typically triggered by another annotation processor or code generator that emits a @GlideModule/@GlideExtension class in a later round.

Common situations: A different processor (Dagger, AutoService, a custom generator) produces a @GlideModule/@GlideExtension in a later round after Glide already wrote its output; incremental/incremental-KAPT misconfiguration causing Glide to run before all sources are visible; an ICE/build-cache corruption that reorders rounds; mixing KSP and KAPT processors on the same module.

Related errors

• Unrecognized type: {}
• Given both modules and extensions, expected one or the other
• Unrecognized annotation: {}
• Expected single value, but found: {}
• Constructor for {} accepts too many parameters, it should ac

AI-assisted analysis of bumptech/glide@eb14a895d8 (2026-08-14). Data as JSON: /api/errors/01d4c0032548c538. Report an issue: GitHub.