-
Notifications
You must be signed in to change notification settings - Fork 27
feat: Add support for per-context summary events. #126
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
const summary = summarizer.getSummary(); | ||
summarizer.clearSummary(); | ||
if (summary) { | ||
summary.kind = 'summary'; |
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.
This moved inside the summarizer.
src/__tests__/canonicalize-test.js
Outdated
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.
Same canonicalization tests as implemented in js-core with test data based on canonicalization spec.
* @param {any[]?} visited The list of objects that have already been visited to avoid cycles. | ||
* @returns {string} The canonicalized JSON string. | ||
*/ | ||
function canonicalize(object, visited = []) { |
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.
Are there limitations to how this can be used to avoid a breaking issue? Like persisting the result or sending the result to the cloud? If so, do you think a notice/warning could be useful?
I think it would be when we formalize context canonicalization across the system and it is different than this rfc.
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.
Currently there isn't any breaking issue possible as it is just used internally. If we did use JSON canonicalization for storage or inside events, then this is the RFC we would be using. It is the same spec we use for canonicalization during event ingest for JSON flag values. It would also be good for usage for a secure mode that uses attributes.
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.
So, not any avoidance I am aware of for this specific implementation. That said if we design a feature where we do use it externally we will want specific validations added as part of that feature. (unless we just use the existing test vectors from the RFC).
🤖 I have created a release *beep* *boop* --- ## [5.7.0](5.6.0...5.7.0) (2025-05-22) ### Features * Add support for per-context summary events. ([#126](#126)) ([05f7d4e](05f7d4e)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
No description provided.