Snapshots expose warnings and errors that are confusing

[natebosch]

Running from a stale snapshot can trigger any number of warnings or errors. Typically this is fine because we'll correctly identify the situation and recreate the snapshot, then the followup build should be successful.

For example you might see a [WARNING] some/file.dart was not found in the asset graph, incremental builds will not work.. This looks scary, but the build will likely succeed on the second run.

I wonder if we can more eagerly invalidate the snapshot by detecting situations where we expect it would fail when we run it.

[jakemac53]

The particular one you mention gets tricky - it can happen due to poorly configured targets too (some sources not being included in any targets). So we can't use that alone as an indication that we need to re-snapshot. We could potentially use the existence of a previous asset graph and that error as an indication that we need to re-snapshot though (and throw a BuildScriptChanged exception).

Are there other specific scenarios we are aware of that are weird?

[natebosch]

You can hit this after a pub upgrade. That might be the only scenario we need to check for specially. Maybe we should keep a hash of the package versions and invalidate the snapshot before running it when that changes.

[jakemac53]

When you have path dependencies (or builders implemented in the current package) this can happen at any time so that makes it more difficult.

[grouma]

Hitting something similar to this today. Rolled a new version of build_runner which expects a new argument for the daemon command. We aren't updating the snapshot script which is causing a failure. Users have to pub run build_runner clean to resolve the issue but we don't automatically direct users to do so.

See:
dart-lang/webdev#375

[jakemac53]

Would one fix here be to record the last version of build_daemon that the snapshot was ran with, and make sure to re-snapshot if that changes? That wouldn't help if you have a path override or something but those cases should be limited to us and rare even then.

[jakemac53]

Alternatively we could always re-snapshot if we hit any unhandled exception?

[natebosch]

I think we should separately record a hash of the pub solve and resnapshot on any pub get.

[jakemac53]

I think we should separately record a hash of the pub solve and resnapshot on any pub get.

My hesitation with that is its overly pessimistic and comes at a pretty high cost, for small projects the snapshot time can be even longer than the entire build time.

[jakemac53]

I believe we handle this much better today (and actually do incremental rebuilds too)