Null check operator used on a null value `Build._hasInputChanged`

[Rexios80]

• Dart 3.8.1
• build_runner: 2.5.3
• json_serializable
• macOS

This issue was introduced in version 2.5.0. It happens when running the build_runner multiple times.

E Unhandled build failure!
  Null check operator used on a null value
  #0      Build._hasInputChanged (package:build_runner_core/src/generate/build.dart:912:44)
  #1      Build._hasInputGraphChanged (package:build_runner_core/src/generate/build.dart:881:19)
  <asynchronous suspension>
  #2      Build._buildShouldRun.<anonymous closure> (package:build_runner_core/src/generate/build.dart:809:13)
  <asynchronous suspension>
  #3      TimedActivities._runAsync (package:build_runner_core/src/logging/timed_activities.dart:105:14)
  <asynchronous suspension>
  #4      Build._buildShouldRun (package:build_runner_core/src/generate/build.dart:743:12)
  <asynchronous suspension>
  #5      Build._buildForPrimaryInput.<anonymous closure> (package:build_runner_core/src/generate/build.dart:480:12)
  <asynchronous suspension>
  #6      Build._runPhases.<anonymous closure>.<anonymous closure> (package:build_runner_core/src/generate/build.dart:336:17)
  <asynchronous suspension>
  #7      Build._runPhases.<anonymous closure> (package:build_runner_core/src/generate/build.dart:331:11)
  <asynchronous suspension>
  #8      Build._safeBuild.<anonymous closure> (package:build_runner_core/src/generate/build.dart:230:22)
  <asynchronous suspension>

[famasf1]

I downgraded to 2.4.15, run build runner, found out where the error from my code was preventing the build, fixed it and revert back to 2.5.3 and was able to continue.

So I'd say generally the error handling could use some serious improvements. The old version prior to refactor is so much better at pinpointing exactly which files is causing error instead of general null check error.

[Rexios80]

I have no errors with the old version

[davidmorgan]

Thank you for the bug report, hopefully we can figure this out and get a fix out quickly.

But I haven't been able to find a repro.

Could you please give more info on how you hit this bug?

e.g. some sequence of builds, edits, deletes that triggers the failure.

Could you confirm if json_serializable is the only builder you're using?

Thanks!

[davidmorgan]

I downgraded to 2.4.15, run build runner, found out where the error from my code was preventing the build, fixed it and revert back to 2.5.3 and was able to continue.

It sounds like you are hitting the same issue? I'm looking for a sequence of what leads to the null check fail.

So, something with: build, editing a file to introduce an error, build again?

Are you also using json_serializable, is the file using json_serializable?

Thanks :)

[Rexios80]

@davidmorgan I am able to reproduce this consistently in the hive folder of https://github.com/IO-Design-Team/hive_ce

If you update the build_runner dependency to 2.5.3 you should see it on the second run

[davidmorgan]

Thanks! I found the issue.

It's triggered by the nested example folder with its own pubspec.

There is a long-standing build_runner issue that such folders are not handled correctly, sources in the nested folder become part of the build but with incorrect deps

#560
#2916

and with the refactor the incorrect deps handling causes a throw.

Fortunately there is an easy workaround, add example to dev_dependencies of hive_ce:

dev_dependencies:
  test: ^1.17.12
  mocktail: ^1.0.4
  rexios_lints: ^12.0.0
  path: ^1.7.0
  pointycastle: ^4.0.0
  build_runner: 2.5.0
  json_serializable: ^6.9.4
  example:
    path:
      example

now the example subfolder will be handled correctly and not as part of the build of hive_ce.

A couple more workarounds:

• switch to using workspaces and use workspace resolution for both hive_ce and for example
• remove pubspec.yaml from example; but this is not a good workaround as you'd have to add some deps to hive_ce just for the example

Of course, I'll look at fixing this properly.

Thanks again!

[davidmorgan]

Okay, this actually relates to a more fundamental issue, if a package import can't be found that causes the crash on the next build. In your case it can't be found because of the nested package confusion, but there's no need for nested packages to trigger this.

Fortunately the missing file handling is simple to fix, I'll do that :)

[davidmorgan]

I think this is now fixed with the 2.5.4 release, please reopen if not. Thanks again for reporting.