[Bug]: Major downgrade bug after 0.3.0 to 1.2.0

[maolaaaa]

Do you need to file an issue?

• I have searched the existing issues and this bug is not already filed.
• My model is hosted on OpenAI or Azure. If not, please look at the "model providers" issue and don't file a new one here.
• I believe this is a legitimate bug, not just a question. If this is a question, please use the Discussions area.

Describe the bug

When running my multi-file project with the latest version of GraphRAG, there are often unexpected interruptions due to llm instability.
When I tried to use cache to recover the data, I found that no matter using resume + timestamp (e.g. graphrag index --root --resume 20250214-171757 (the timestamp is in indexing-engine.log)) or defaulting to cache, I couldn't do the cache recovery work correctly. to restore the cache.
After re-downloading v0.3.0, I found that when interrupting either accidentally or manually by ctrl+C, I can run python -m graphrag.index --root again to recover the cache, probably due to the collaborator's changes.

Steps to reproduce

No response

Expected Behavior

No response

GraphRAG Config Used

# Paste your config here

Logs and screenshots

No response

Additional Information

• GraphRAG Version:
• Operating System:
• Python Version:
• Related Issues:

[schauerstoff]

same here, but I don't even see the "20250214-171757" timestamp in the logs. According to previous instructions how to resume, this should be the name of a subfolder of the cache directory, but I don't see them being created in version 1.2.0.

[shawn-maxiao]

same here, but I don't even see the "20250214-171757" timestamp in the logs. According to previous instructions how to resume, this should be the name of a subfolder of the cache directory, but I don't see them being created in version 1.2.0.

yes. No timestamp named folder created in 1.2.0. Very strange.

[natoverse]

We've been working through a number of issues since adopting fnllm for API call management. 2.0.0 was just released, which we believe resolves these issues.