-
-
Notifications
You must be signed in to change notification settings - Fork 91
Add Context.getActorFirstKeyByUsage and Context.getActorKeysByUsage #553
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
Summary of ChangesHello @tibisabau, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request enhances the Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
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.
Code Review
This pull request introduces two convenient helper methods, getActorKeysByUsage() and getActorFirstKeyByUsage(), to simplify retrieving actor keys from the context. The changes are well-structured across the interface, implementation, and testing files.
My review focuses on improving the robustness and readability of the new implementations. I've identified a critical issue in getActorFirstKeyByUsage where it doesn't handle cases where no keys are available, which could lead to runtime errors. I've provided a suggestion to fix this and also to refactor both new methods to use async/await for better consistency with the existing codebase. Additionally, I've suggested a minor naming improvement in the test mocks for better clarity.
Once these points are addressed, this will be a solid enhancement to the library's developer experience.
| getActorKeysByUsage(identifier: string): Promise<{ | ||
| publicKeys: CryptographicKey[]; | ||
| assertionMethods: Multikey[]; | ||
| }> { | ||
| return this.getActorKeyPairs(identifier) | ||
| .then((keys) => ({ | ||
| publicKeys: keys.map((k) => k.cryptographicKey), | ||
| assertionMethods: keys.map((k) => k.multikey), | ||
| })); | ||
| } | ||
|
|
||
| getActorFirstKeyByUsage(identifier: string): Promise<{ | ||
| publicKey: CryptographicKey; | ||
| assertionMethod: Multikey; | ||
| }> { | ||
| return this.getActorKeysByUsage(identifier) | ||
| .then(({ publicKeys, assertionMethods }) => ({ | ||
| publicKey: publicKeys[0], | ||
| assertionMethod: assertionMethods[0], | ||
| })); | ||
| } |
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.
These new methods can be improved for readability and robustness.
- Both methods can be simplified by using
async/awaitinstead of.then(), which is more consistent with the surrounding code style. getActorFirstKeyByUsagehas a potential runtime error. IfgetActorKeysByUsagereturns empty arrays, accessingpublicKeys[0]andassertionMethods[0]will result inundefined, which violates the return type contract. You should add a check for empty arrays and throw an error if no keys are found, similar to the behavior in the testing context.
async getActorKeysByUsage(identifier: string): Promise<{
publicKeys: CryptographicKey[];
assertionMethods: Multikey[];
}> {
const keys = await this.getActorKeyPairs(identifier);
return {
publicKeys: keys.map((k) => k.cryptographicKey),
assertionMethods: keys.map((k) => k.multikey),
};
}
async getActorFirstKeyByUsage(identifier: string): Promise<{
publicKey: CryptographicKey;
assertionMethod: Multikey;
}> {
const { publicKeys, assertionMethods } = await this.getActorKeysByUsage(
identifier,
);
if (publicKeys.length < 1 || assertionMethods.length < 1) {
throw new Error(`No actor keys available for identifier: ${identifier}`);
}
return {
publicKey: publicKeys[0],
assertionMethod: assertionMethods[0],
};
}| getActorKeysByUsage: getActorKeysByUsage ?? | ||
| ((_handle) => | ||
| Promise.resolve({ | ||
| publicKeys: [], | ||
| assertionMethods: [], | ||
| })), | ||
| getActorFirstKeyByUsage: getActorFirstKeyByUsage ?? | ||
| ((_handle) => { | ||
| throw new Error("No actor keys available"); | ||
| }), |
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.
For consistency with the method signatures in the Context interface, which use identifier as the parameter name, it would be clearer to name the parameter _identifier instead of _handle in these mock implementations.
| getActorKeysByUsage: getActorKeysByUsage ?? | |
| ((_handle) => | |
| Promise.resolve({ | |
| publicKeys: [], | |
| assertionMethods: [], | |
| })), | |
| getActorFirstKeyByUsage: getActorFirstKeyByUsage ?? | |
| ((_handle) => { | |
| throw new Error("No actor keys available"); | |
| }), | |
| getActorKeysByUsage: getActorKeysByUsage ?? | |
| ((_identifier) => | |
| Promise.resolve({ | |
| publicKeys: [], | |
| assertionMethods: [], | |
| })), | |
| getActorFirstKeyByUsage: getActorFirstKeyByUsage ?? | |
| ((_identifier) => { | |
| throw new Error("No actor keys available"); | |
| }), |
|
Did you vibe-code it? Please read our AI usage policy first. Thanks. |
AI Assistance is disclosed at the bottom of the PR description. Is there something else I missed? |
|
No unit tests and wrong documentation ( |
Summary
Added
Context.getActorKeysByUsage()andContext.getActorFirstKeyByUsage()methods to simplify retrieval of actor keys grouped by usage type for
ActivityPub actor dispatchers.
Related issue
Context.getActorFirstKeyByUsage(id)andContext.getActorKeysByUsage(id). #488Changes
getActorKeysByUsage()method signature toContextinterface inpackages/fedify/src/federation/context.ts
getActorFirstKeyByUsage()method signature toContextinterfacein packages/fedify/src/federation/context.ts
getActorKeysByUsage()method inContextImplclass inpackages/fedify/src/federation/middleware.ts
getActorFirstKeyByUsage()method inContextImplclass inpackages/fedify/src/federation/middleware.ts
in packages/fedify/src/testing/context.ts
Benefits
dispatchers
publicKey(CryptographicKey) andassertionMethod(Multikey) usage explicit and clearmost common use cases
Checklist
mise teston your machine?Additional notes
The code in this pull request was generated by GitHub Copilot with the Claude Sonnet 4.5 model.