Add an error variant to Saved_state_fetcher.fetch_result

Summary:
Previously, this variant type did not distinguish between the case where we tried to find saved state and failed (e.g. local fetcher) and the case where we simply did not bother to look for saved state (e.g. the dummy fetcher).

This leads to an inconsistency where a failure to find the saved state and a failure to read the saved state are handled in completely different ways. This is illustrated by the test added in D20252511.

This diff adds the additional variant needed to distinguish between failing to find saved state and choosing not to look for saved state. For now, they are handled identically, but future diffs will change that.

Reviewed By: mroch

Differential Revision: D20236637

fbshipit-source-id: 5da544d66c3982af95ea568a09754d615a640ff0

src/services/inference/types_js.ml

@@ -2812,7 +2812,8 @@ let load_saved_state ~profiling ~workers options =
   in
   Profiling_js.merge ~from:fetch_profiling ~into:profiling;
   match fetch_result with
-  | Saved_state_fetcher.No_saved_state ->
+  | Saved_state_fetcher.No_saved_state
+  | Saved_state_fetcher.Saved_state_error ->
     Hh_logger.info "No saved state available";
     Lwt.return_none
   | Saved_state_fetcher.Saved_state { saved_state_filename; changed_files } ->

src/services/saved_state/saved_state_fetcher.ml

@@ -6,11 +6,15 @@
  *)
 
 type fetch_result =
+  (* We successfully found saved state. Yay! *)
   | Saved_state of {
       saved_state_filename: Path.t;
       changed_files: SSet.t;
     }
+  (* We did not attempt to find saved state. *)
   | No_saved_state
+  (* We should have been able to find saved state , but for some reason we could not. *)
+  | Saved_state_error
 
 module type FETCHER = sig
   val fetch : options:Options.t -> (Profiling_js.finished * fetch_result) Lwt.t