Snapshots expose warnings and errors that are confusing #1929
Comments
|
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? |
|
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. |
|
When you have path dependencies (or builders implemented in the current package) this can happen at any time so that makes it more difficult. |
|
Hitting something similar to this today. Rolled a new version of See: |
|
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. |
|
Alternatively we could always re-snapshot if we hit any unhandled exception? |
|
I think we should separately record a hash of the pub solve and resnapshot on any |
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. |
…#2374) Related to #1929 I ended up going with the build_runner/build_daemon version check since the error handling was going to get pretty gnarly once I looked at what it would actually take. The check is done by examining where a fake uri resolves to for each package, since that actually catches some cases the version check alone wouldn't catch and it doesn't require reading/parsing any files. Note that this will not catch cases where you have a path override on these packages as that path won't ever change even if the packages do, but that should only affect us internally.
|
I believe we handle this much better today (and actually do incremental rebuilds too) |
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.
The text was updated successfully, but these errors were encountered: