how to correctly to resume work

[tusik]

my config is

cache:
  type: file # one of [blob, cosmosdb, file]
  base_dir: "cache"

i'm index 100M files, embedding api have some problem when extract graph is finished, i'm tring to resume work

graphrag index --root . --resume [timestamp find in index-eninge.log]

# index-engine.log
09:14:04,701 graphrag.cli.index INFO Starting pipeline run for: 20250110-091404, dry_run=False
# why hide the timestamp, it just only write in index-eninge.log now, no screen output, no named cache folder

And just re-extract graph now, is something i did wrong?
So resume not work just waste my 200M tokens from last work?

[ultrageopro]

same problem

[schauerstoff]

same here

[hejiang1972]

same problem

[quying]

I have the same situation where I have only embedding pipeline failed and do not want to rerun everything else. I checked doc and code, I didn't find resume option. But I did find a "workflow" config where you can specify the pipelines.
Check out here doc

[schauerstoff]

When I just re-ran it (v1.2.0) without any changes it automatically used the cache after the graph-creation process. Might be worth a try

[chenfan001]

Have you succeeded in your attempt? Could you please share the configuration? I tried according to the documentation, but I found that I couldn't skip the workflows that have already been run. When setting the workflow list, it will show that the specific workflow is not configured. Looking forward to your reply!

[schauerstoff]

Yes, it did succeed on v1.2, did not attempt again on v2.1. I left the workflow list as is and just called the indexing routine again which automatically used the stored data in /cache

[chenfan001]

thank u

[EmmittXu]

I tried --resume and skip_workflows, both not working. But here is a hardcode way out, comment "_get_workflow_list" function

[VanillaTY]

I added workflows configuration in the settings.yaml file, and successfully resolved! https://microsoft.github.io/graphrag/config/yaml/

[natoverse]

GraphRAG caches LLM calls aggressively, so re-running after a failure should skip over all the previous work. If that still takes a long time due to CPU processing as it runs through the workflows, the solution by @VanillaTY is correct: the workflows key in your settings.yml can be used to run exactly and only the listed workflows.