-
Notifications
You must be signed in to change notification settings - Fork 2k
[ENH]: Add collection metadata to output collection to identify source attached function #5955
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Reviewer ChecklistPlease leverage this checklist to ensure your code review is thorough before approving Testing, Bugs, Errors, Logs, Documentation
System Compatibility
Quality
|
This stack of pull requests is managed by Graphite. Learn more about stacking. |
|
Add metadata flag to output collections and block function chaining The PR introduces metadata tagging for attached-function output collections and uses that marker to prevent attaching another function to the same collection. It also wires the new error through the coordinator, updates constants, and adds regression coverage in Go and Python tests to validate the new guard. Key Changes• Set Affected Areas• This summary was automatically generated by @propel-code-bot |
f782230 to
3acb2ad
Compare
…collections - Add chroma:attached_function_id metadata when creating output collections - Add check in AttachFunction to prevent attaching functions to output collections - Add ErrCannotAttachToOutputCollection error
3acb2ad to
dbbe74c
Compare
|
|
||
| // SourceAttachedFunctionIDKey is the metadata key used to mark output collections | ||
| // and link them to their attached function. | ||
| SourceAttachedFunctionIDKey = "chroma:source_attached_function_id" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Which reads better:
- "source attached function id"
- "attached function id source"

Description of changes
Summarize the changes made by this PR.
Test plan
How are these changes tested?
pytestfor python,yarn testfor js,cargo testfor rustMigration plan
Are there any migrations, or any forwards/backwards compatibility changes needed in order to make sure this change deploys reliably?
Observability plan
What is the plan to instrument and monitor this change?
Documentation Changes
Are all docstrings for user-facing APIs updated if required? Do we need to make documentation changes in the docs section?