Missing dependencies - but only sometimes

[holzgeist]

Hi there,

Since the latest release I get warnings about missing dependencies like this:

Missing dependencies in our_app/dependencies.dart

[ServiceA] depends on unregistered type [ServiceB] from package:app/services/service_b.dart

Did you forget to annotate the above class(s) or their implementation with @injectable? 
or add the right environment keys?

However, it's not 100% reproducible and I haven't found a minimal reproducible example yet. For our app it happens in ~50% of runs of dart run build_runner build locally and 100% runs on the same repo/checkout in Github Actions. Also, it's not always the same services affected. And sometimes, it just runs through correctly.

With bisecting I could narrow it down to the last commit in this repo 9aa237b

Despite the lack of a reproducible example, I have some more information on where stuff breaks:

• the generated our_app/lib/dependencies.config.dart is broken:
  It contains an import in the top section looking like import 'package:our_app/services/service_b.dart' as _i119;.
  The registration of ServiceB doesn't use the alias though: gh.singleton<ServiceB>(() => ServiceB());
  The registration of ServiceA does use the alias: gh.singleton<_i698.ServiceA>(() => _i698.ServiceA(gh<_i119.ServiceB>());
  Because ServiceB is not defined, anything that imports dependencies.config.dart won't compile.
• the cached json in .dart_tool/build/generated/our_app/lib/services/service_b.injectable.json contains the following (note the null import):

[
  {
    "type": {
      "import": null,
      "name": "ServiceB",
      "isNullable": false,
      "isRecordType": false,
      "nameInRecord": null
    },
    "typeImpl": {
      "import": null,
      "name": "ServiceB",
      "isNullable": false,
      "isRecordType": false,
      "nameInRecord": null
    },
    "isAsync": false,
    "postConstructReturnsSelf": false,
    "preResolve": false,
    "canBeConst": false,
    "injectableType": 1,
    "dependsOn": [],
    "environments": [],
    "dependencies": [],
    "constructorName": "",
    "orderPosition": 0
  }
]

However, the same file for ServiceA looks like this (simplified, it has more dependencies in our app; note the valid import in the dependency to service b):

[
  {
    "type": {
      "import": "package:our_app/services/service_a.dart",
      "name": "ServiceA",
      "isNullable": false,
      "isRecordType": false,
      "nameInRecord": null
    },
    "typeImpl": {
      "import": "package:our_app/services/service_a.dart",
      "name": "ServiceA",
      "isNullable": false,
      "isRecordType": false,
      "nameInRecord": null
    },
    "isAsync": false,
    "postConstructReturnsSelf": false,
    "preResolve": false,
    "canBeConst": false,
    "injectableType": 1,
    "dependsOn": [],
    "environments": [],
    "dependencies": [
      {
        "type": {
          "import": "package:our_app/services/service_b.dart",
          "name": "ServiceB",
          "isNullable": false,
          "isRecordType": false,
          "nameInRecord": null
        },
        "instanceName": null,
        "paramName": "_serviceB",
        "isFactoryParam": false,
        "isPositional": true
      }
    ],
    "constructorName": "",
    "orderPosition": 0
  }
]

both ServiceA and ServiceB are annotated with @singleton.

Is this enough information to narrow down the problem? I can provide more data if you tell me how to get it :)

[holzgeist]

Update:
I traced the issue being in this line:

injectable/injectable_generator/lib/resolvers/importable_type_resolver.dart

Line 66 in 9aa237b

lib.exportNamespace.definedNames.values.contains(element)) {

The condition is false even if the service is defined in the given file.

Therefore I extended the bisect on dart analyzer, which resulted in this commit being the offending one dart-lang/sdk@6494efb which fits the problem perfectly

Basically dart analyzer relies on identical now, which is only true if the "... two object references are to the same object" according to the docs

I traced the call stack as far up as I could and it looks like lib in the above call site originates from the buildStep argument in the builder entrypoint and element originates from library:

injectable/injectable_generator/lib/generators/injectable_generator.dart

Line 33 in 9aa237b

FutureOr<String?> generate(LibraryReader library, BuildStep buildStep) async {

My assumtion:
It looks like those arguments are sometimes re-created by build_runner (?) and sometimes passed through.
Does that ring a bell? 😇

[holzgeist]

Reported in dart analyzer: dart-lang/sdk#59947

Now I'll wait for someone more familiar with the matter to have a look, I'm way out of my comfort zone with dart 😄