What version of Oxlint are you using?

1.58.0

What command did you run?

oxlint -D eslint/no-unused-private-class-members awaited-private-field.js

What does your .oxlintrc.json (or oxlint.config.ts) config file look like?

I am not using a config file for the minimal repro.

What happened?

Oxlint reports a private field as unused when it is only read through await.

Minimal repro:

class AwaitedPrivateField {
   #promise = Promise.resolve();

   async stop() {
      await this.#promise;
   }
}

Actual behavior:

eslint(no-unused-private-class-members): 'promise' is defined but never used.

Expected behavior:

No diagnostic. await this.#promise is a value read of the private field.

Related application shape:

class Stopper {
   #promise;

   async stop() {
      this.#promise ??= this.makePromise();
      await this.#promise;
   }

   makePromise() {
      return Promise.resolve();
   }
}

That shape is also flagged, but the smaller await this.#promise example reproduces the core issue by itself.

Additional context:

• PR fix(linter/no-unused-private-class-members): correctly detect value context for private members in assignment expressions #15553 fixed value-context detection for private members used on the right-hand side of assignments.
• PR fix(linter/no-unused-private-class-members): treat logical lhs access as usage #19991 fixed logical-expression left-hand-side usage such as this.#flag && doThing().
• Current main appears to have passing coverage for return this.#prop ??= 0, but the rule tests still include class Foo { #awaitedMember; async method() { await this.#awaitedMember; } } in the failing set.

That suggests this is a remaining read-context gap for AwaitExpression, not a case already covered by the existing fixes.

Possible implementation direction:

is_value_context already recurses through AwaitExpression, but is_read currently falls through to false for the immediate PrivateFieldExpression -> AwaitExpression pair before that recursive value-context check can count it as a read.