fix. Even if you think it's relatively minor, it's helpful to know what people
are working on. And as mentioned above, API changes should be discussed
thoroughly before moving to code.

Some examples of types of pull requests that are immediately helpful:

  - Fixing a bug without changing a public API.
  - Fixing or improving documentation.
  - Improvements to Maven configuration.

  private val listener = EventSourceRecorder()
  private var client =
    clientTestRule.newClientBuilder()
      .eventListenerFactory(clientTestRule.wrap(eventListener))
      .build()

  @BeforeEach
  fun before(server: MockWebServer) {
    this.server = server
  }

  @AfterEach
  fun after() {
    listener.assertExhausted()
  }

  @Test
  fun event() {
    server.enqueue(
      MockResponse.Builder()

 *   <li>NullAway, which will <a
 *       href="https://github.com/google/guava/issues/6126#issuecomment-1204399671">treat it
 *       identically to {@code Nullable} as of version 0.9.9</a>. To treat it that way before then,
 *       you can set {@code
 *       -XepOpt:NullAway:CustomNullableAnnotations=com.google.common.base.ParametricNullness,...,com.google.common.util.concurrent.ParametricNullness},

   * the entry was returned by the iterator, except through the setValue operation on the map entry"
   * As such, this field must be cleared before every map mutation.
   *
   * Note about volatile: volatile doesn't make it safe to read from a mutable graph in one thread
   * while writing to it in another. All it does is help with _reading_ from multiple threads

 *   <li>NullAway, which will <a
 *       href="https://github.com/google/guava/issues/6126#issuecomment-1204399671">treat it
 *       identically to {@code Nullable} as of version 0.9.9</a>. To treat it that way before then,
 *       you can set {@code
 *       -XepOpt:NullAway:CustomNullableAnnotations=com.google.common.base.ParametricNullness,...,com.google.common.util.concurrent.ParametricNullness},

 *   <li>NullAway, which will <a
 *       href="https://github.com/google/guava/issues/6126#issuecomment-1204399671">treat it
 *       identically to {@code Nullable} as of version 0.9.9</a>. To treat it that way before then,
 *       you can set {@code
 *       -XepOpt:NullAway:CustomNullableAnnotations=com.google.common.base.ParametricNullness,...,com.google.common.util.concurrent.ParametricNullness},

 *   <li>NullAway, which will <a
 *       href="https://github.com/google/guava/issues/6126#issuecomment-1204399671">treat it
 *       identically to {@code Nullable} as of version 0.9.9</a>. To treat it that way before then,
 *       you can set {@code
 *       -XepOpt:NullAway:CustomNullableAnnotations=com.google.common.base.ParametricNullness,...,com.google.common.util.concurrent.ParametricNullness},

 *   <li>NullAway, which will <a
 *       href="https://github.com/google/guava/issues/6126#issuecomment-1204399671">treat it
 *       identically to {@code Nullable} as of version 0.9.9</a>. To treat it that way before then,
 *       you can set {@code
 *       -XepOpt:NullAway:CustomNullableAnnotations=com.google.common.base.ParametricNullness,...,com.google.common.util.concurrent.ParametricNullness},

   * index n is done, the output future at index n-1 is also done. (But as usual with futures, some
   * listeners for future n may complete before some for future n-1.) However, it is possible, if
   * one input completes with result X and another later with result Y, for Y to come before X in
   * the output future list. (Such races are impossible to solve without global synchronization of

  private var timeoutEarlyExit = false

  /**
   * This is the same value as [exchange], but scoped to the execution of the network interceptors.
   * The [exchange] field is assigned to null when its streams end, which may be before or after the
   * network interceptors return.
   */
  internal var interceptorScopedExchange: Exchange? = null
    private set