Cache bundle graph on failure

[irismoini]

↪️ Pull Request

This PR adds logic to write Parcel's bundle graph to the cache if an error occurs during bundling.

Currently Parcel’s requestGraph is written to the cache at the end of a build or when interrupted with ctrl-c. Parcel’s bundleGraph is stored in node.value.results in the requestGraph and is written to the cache as part of the requestGraph's write to cache. If an error occurs during bundling however, the bundleGraph is never stored in a requestGraph node and as a result isn't written to the cache. This PR adds code to also store the bundleGraph in a requestGraph node if an error occurs during bundling.

Ideally, we'd eventually like to be able to replicate failed builds from the Parcel cache and this PR is a step towards that.

💻 Examples

NA

🚨 Test instructions

NA

✔️ PR Todo

• Added/updated unit tests for this change
• Filled out test instructions (In case there aren't any unit tests)
• Included links to related issues/PRs

[irismoini]

Not sure if this is the best way to determine the bundleGraphPath. Currently being determined here . Which means if that changes, this code will break, but I have no way of accessing this function directly, so this is currently hardcoded.

[lettertwo]

Maybe getFilePath() should be added to the Cache interface? /cc @JakeLane

[JakeLane]

Yeah I think that would be reasonable.

Though I think it would be more maintainable for the integration test if we used the cache interface to load the blob instead, as we're duplicating business logic here.

[mischnic]

Is the goal of the this change to be able to access the graphs via parcel-query? You could use that in the test

[irismoini]

@mischnic For now we're just looking to confirm that the bundleGraph is written to cache if an error occurs during bundling w/ the ultimate goal of being able to replicate errors from the parcel cache.
@JakeLane I made a change based on what I thought you meant, lmk if you meant something else!