Repository navigation
Fallback to full run if protocol deps are missing/invalid instead of crashing/failing - #5004
Conversation
| # the protocol cache against the loaded individual cache files. | ||
| TypeState.proto_deps = read_protocol_cache(manager, graph) | ||
| if TypeState.proto_deps is None and manager.stats.get('fresh_trees', 0) > 0: | ||
| if TypeState.proto_deps is None and manager.stats.get('fresh_metas', 0) > 0: |
There was a problem hiding this comment.
It would be good to have a test case for this, since this is something that could easily get stale. Maybe create an issue about adding a test (maybe also for other related cache corruption issues)?
There was a problem hiding this comment.
We already have #5002, do we need a separate issue? I can just add a comment that we need to also check performance/behavior with corrupted caches.
| manager.cache_enabled = False | ||
| TypeState.proto_deps = {} | ||
| manager.log("Falling back to full run -- reloading graph...") | ||
| graph = load_graph(sources, manager) |
There was a problem hiding this comment.
Should we call update_protocol_deps as well? This might be less likely to get stale if we'd only have one process_graph callin this function. Maybe instead of calling load_graph and process_graph here, call dispatch recursively after changing the options?
There was a problem hiding this comment.
Should we call
update_protocol_depsas well?
I think no, since update.py should do this. We call it manually below to have them up to date if we write caches. Anyway, I think calling dispatch recursively is a better option, so we don't need to worry about keeping the logic in sync.
Also change the cache file names to
@proto_depsto avoid clashes with user modules with the same name.