fix(deploy): normalize trigger provider aliases before cloud deploy - #227
Conversation
|
Warning Review limit reached
More reviews will be available in 48 minutes and 48 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more credits in the billing tab to continue. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces local skill source resolution for personas, allowing relative local skill paths to resolve against the persona JSON directory, and adds trigger provider alias normalization in the deploy preflight step. The review feedback highlights three key improvements: merging trigger arrays during normalization to prevent accidental overwrites, adding defensive checks to handle null or non-object skill elements gracefully, and running trigger linting on the raw agent configuration before normalization to ensure warning paths match the user's source files.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| const normalized: NonNullable<AgentSpec['triggers']> = {}; | ||
| for (const [provider, list] of Object.entries(triggers)) { | ||
| normalized[aliases[provider] ?? provider] = list; | ||
| } |
There was a problem hiding this comment.
If an agent configures triggers for both an alias and its canonical counterpart (or multiple aliases mapping to the same canonical name in the future), the current implementation will silently overwrite previous entries in the normalized object. Merging the trigger arrays instead of overwriting them prevents accidental loss of configured triggers.
const normalized: NonNullable<AgentSpec['triggers']> = {};
for (const [provider, list] of Object.entries(triggers)) {
const canonical = aliases[provider] ?? provider;
normalized[canonical] = normalized[canonical]
? [...normalized[canonical], ...list]
: list;
}| return skills.flatMap((skill) => { | ||
| const source = skill.source; |
There was a problem hiding this comment.
At runtime, skills elements are not guaranteed to be non-null objects before validation. If a user provides an invalid/null skill in their JSON, skill.source will throw a TypeError and crash the CLI. Adding a defensive check ensures that invalid skill entries are handled gracefully and can be caught by the downstream schema validator instead of crashing.
return skills.flatMap((skill) => {
if (!skill || typeof skill !== 'object') {
return [skill];
}
const source = skill.source;| const normalizedAgent = normalizeTriggerProviderAliases(agent); | ||
|
|
||
| const triggerLint = lintTriggers(normalizedAgent); |
There was a problem hiding this comment.
Running lintTriggers on the normalizedAgent causes any trigger warnings to report paths using the canonical provider name (e.g., triggers.gmail[0].on) instead of the alias name actually written in the user's source code (e.g., triggers.google-mail[0].on). Running lintTriggers on the raw agent first ensures that the warning paths match the user's source files exactly, improving developer experience.
| const normalizedAgent = normalizeTriggerProviderAliases(agent); | |
| const triggerLint = lintTriggers(normalizedAgent); | |
| const triggerLint = lintTriggers(agent); | |
| const normalizedAgent = normalizeTriggerProviderAliases(agent); |
|
Implemented two fixes from validated review feedback:
Addressed comments
Advisory NotesNone. Validation run locally:
All passed locally. Remote PR metadata still reports |
|
Reviewed PR #227 against Local CI-equivalent verification run:
Addressed comments
Advisory NotesThe artifact comments under I cannot print |
Aliases like 'google-mail' are valid integration provider ids (used in
persona.integrations and by the cloud's integration connect flow), but
the cloud's trigger-subscription API only accepts canonical adapter names
('gmail'). KNOWN_TRIGGER_PROVIDER_ALIASES already handled local lint
warnings; this gap meant the preflight passed cleanly locally but the
cloud returned 400 unsupported_trigger on deploy.
Add normalizeTriggerProviderAliases() in preflight.ts that runs AFTER the
integration-provider cross-check (so 'google-mail' still matches
persona.integrations['google-mail']) and replaces alias keys with their
canonical counterparts before the agent spec is returned and serialized
into the cloud deploy payload.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
01c45b0 to
fccd17c
Compare
|
Fixed a PR-scoped downstream regression from trigger-provider normalization. The PR normalizes Added coverage:
Addressed comments
Advisory Notes
Local validation run:
All completed successfully locally. I also checked for conflict markers and found none. I did not print |
|
Fixed two PR-scope issues:
Added regression coverage in Addressed comments
Advisory Notes
Validation run locally with the repo’s CI-equivalent build/test path:
All completed successfully. |
|
pr-reviewer could not complete review for #227 in AgentWorkforce/workforce. |
1 similar comment
|
pr-reviewer could not complete review for #227 in AgentWorkforce/workforce. |
1 participant
Summary
packages/deploy/src/preflight.ts: after the persona/agent integration cross-check, applyKNOWN_TRIGGER_PROVIDER_ALIASESto rewrite trigger provider keys to their canonical names before the agent spec is returned and serialized into the cloud deploy payloadWhy
The cloud's trigger-subscription API uses canonical adapter slugs (
gmail,slack, …). Persona authors — and the runtime's own alias map — use the integration provider id instead (google-mail).KNOWN_TRIGGER_PROVIDER_ALIASESalready backed the local lint warnings but was never applied to the outbound spec, so deploys failed at the cloud with:The fix runs after the integration cross-check so
google-mailinagent.triggersstill matchespersona.integrations['google-mail'](alias = alias). Only the spec handed to the cloud launcher gets canonical names.Merge order
Merge
AgentWorkforce/relayfile-adapters#170first (addsgranola.file.createdto the trigger catalog). This PR has no hard dependency on it, but the two fixes address the same deploy session and the catalog update silences the remaining lint warning once this lands.Test plan
deadline-watcher— 400unsupported_triggerforgoogle-mail:file.createdshould be gonelintTriggerstests still pass (npm test -w packages/persona-kit)'google-mail'trigger validates correctly and returns'gmail'in the agent spec🤖 Generated with Claude Code