Feat/additional context

[AlonsoGuevara]

Description

Add additional_context dictionary bag at api level for custom workflows support

Related Issues

[Reference any related issues or tasks that this pull request addresses.]

Proposed Changes

[List the specific changes made in this pull request.]

Checklist

• I have tested these changes locally.
• I have reviewed the code changes.
• I have updated the documentation (if necessary).
• I have added appropriate unit tests (if applicable).

Additional Notes

[Add any additional notes or context that may be helpful for the reviewer(s).]

[natoverse]

Given that this is essentially just providing a way to pre-set some values in the context.json if it doesn't already exist, what would you think about naming it init_context or something like that, and then if present it just becomes the state from context.json instead of trying to read it?

[AlonsoGuevara]

Given that this is essentially just providing a way to pre-set some values in the context.json if it doesn't already exist, what would you think about naming it init_context or something like that, and then if present it just becomes the state from context.json instead of trying to read it?

Thanks for the suggestion, @natoverse.

• Why I kept additional_context: We will be using that bag to pass non-serializable / runtime-only objects (e.g., open DB connections, in-memory caches) that we don’t want written to context.json.

• Why I left context.json as-is: That file persists essential, serializable state between runs so our core workflows can pick it up the next time.

Because those two buckets serve different purposes (ephemeral vs. persisted), renaming to init_context and overriding the whole JSON file would conflate them.

If we still feel the name is confusing, I’m open to alternatives—maybe something like runtime_context or volatile_context to emphasise its non-persistent nature. Let me know what you think!

[natoverse]

Ok, that makes sense. I had thought you may be planning to allow non-serializable objects, but don't see where we exclude it when context.json is dumped.

[Copilot]

Pull Request Overview

This PR adds support for passing additional context to GraphRAG pipeline runs through a new additional_context parameter. This enables custom workflows to access user-defined parameters during pipeline execution.

• Adds additional_context parameter to both API and pipeline execution layers
• Stores additional context in pipeline state under additional_context key
• Excludes additional context from persisted state to avoid potential serialization issues

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
graphrag/api/index.py	Adds additional_context parameter to build_index API function with documentation
graphrag/index/run/run_pipeline.py	Implements additional context storage in pipeline state and excludes it from JSON serialization
.semversioner/next-release/minor-20250807204918927024.json	Version bump configuration for minor release