Skip to content

fix(ci): collect trigger types instead of trigger instances#73

Merged
guibeira merged 1 commit intomainfrom
fix/publish-collect-trigger-types
May 4, 2026
Merged

fix(ci): collect trigger types instead of trigger instances#73
guibeira merged 1 commit intomainfrom
fix/publish-collect-trigger-types

Conversation

@guibeira
Copy link
Copy Markdown
Collaborator

@guibeira guibeira commented May 4, 2026

Summary

skills v0.1.3 published successfully (run) but with triggers=[], even though the worker exposes two trigger types:

// skills/src/trigger_types.rs:115-128
iii.register_trigger_type(RegisterTriggerType::new("skills::on-change", ...));
iii.register_trigger_type(RegisterTriggerType::new("prompts::on-change", ...));

collect_worker_interface.py was calling engine::triggers::list, which returns trigger instances (subscriptions some other worker has registered), not the trigger types the worker itself defines. Inside the publish job only the target worker is connected, so the instances list is empty by construction — and trigger types we actually want to publish never show up.

Fix

  • collect_worker_interface.py: query engine::trigger-types::list with include_internal: false (engine drops its own engine::* types).
  • build_publish_payload.py: map TriggerTypeInfo (defined in iii-hq/iii engine_fn/mod.rs:121-128) to the registry trigger schema:
    • idname (e.g. skills::on-change)
    • descriptiondescription
    • trigger_request_formatinvocation_schema
    • call_request_formatreturn_schema
  • Drop _derive_trigger_name / _slug and the instance-shape fields in _normalize_registry_trigger. The collect path emits registry-shape entries directly, so build_payload's passthrough now just enforces the schema.

Test plan

  • After merge, dispatch create-tag.yml for skills with tag=next.
  • Collect worker interface step prints triggers containing two entries with names skills::on-change and prompts::on-change.
  • POST /publish returns 200, registry shows both trigger types on the skills entry.
  • Publish image-resize (or any other worker that doesn't register trigger types) — triggers stays empty, no regression.

Summary by CodeRabbit

  • Chores
    • Refactored internal build and worker collection scripts to improve trigger data processing architecture. Worker interface normalization now leverages trigger type metadata instead of individual trigger instances, enabling more efficient and streamlined data handling.

skills/v0.1.3 published with triggers=[] even though the worker exposes two trigger types (`skills::on-change`, `prompts::on-change`). collect_worker_interface was calling `engine::triggers::list`, which returns trigger INSTANCES (subscriptions registered by other workers), not the trigger TYPES the worker itself exposes for others to subscribe to. With only the target worker connected during publish, the instances list is empty by definition.

Switch the live collection to `engine::trigger-types::list` (with `include_internal: false` so the engine::* types are filtered out by the engine itself) and map each TriggerTypeInfo entry to the registry trigger schema:
- `id` → `name`            (e.g., `skills::on-change`)
- `description` → `description`
- `trigger_request_format` → `invocation_schema`
- `call_request_format` → `return_schema`

Drop `_derive_trigger_name` / `_slug` / the instance-shape fields in `_normalize_registry_trigger`: the live path now produces registry-shape entries directly, and the `build_payload` interface.json passthrough only needs to enforce the registry shape.
@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented May 4, 2026

📝 Walkthrough

Walkthrough

The pull request refactors trigger collection and normalization in build scripts from processing trigger instances to processing trigger types. The worker-interface pipeline now calls engine::trigger-types::list, filters results by type ID, and normalizes using a new helper function, replacing the previous trigger-instance-based workflow that matched triggers to function IDs.

Changes

Trigger Type-Based Processing Pipeline

Layer / File(s) Summary
Data Collection
.github/scripts/collect_worker_interface.py
collect_trigger_types() replaces collect_triggers(), calling engine::trigger-types::list instead of engine::triggers::list.
Core Normalization
.github/scripts/build_publish_payload.py
_normalize_registry_trigger_type() helper added to map trigger-type IDs to output fields with trigger_request_format and call_request_format normalization.
Integration & Signature Update
.github/scripts/build_publish_payload.py
normalize_worker_interface() signature updated: triggers_json replaced by trigger_types_json; iteration logic now processes trigger types and filters out engine:: entries instead of matching function IDs.
Cleanup
.github/scripts/build_publish_payload.py
re import removed; _normalize_registry_trigger rewritten to read name directly from trigger object instead of deriving via regex slug logic; function-ID-based matching removed.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

  • iii-hq/workers#67: Directly modifies the same build scripts and worker-interface collection logic to transition from triggers to trigger types.

Suggested reviewers

  • sergiofilhowz

Poem

🐰 From triggers old to types anew,
We skip the slugs and paths we knew,
No regex roam, no ID dance—
Just names and types in sweet advance!

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately reflects the main objective: changing from collecting trigger instances to collecting trigger types for proper publishing.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch fix/publish-collect-trigger-types

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.

❤️ Share
Review rate limit: 0/1 reviews remaining, refill in 60 minutes.

Comment @coderabbitai help to get the list of available commands and usage tips.

@guibeira guibeira marked this pull request as ready for review May 4, 2026 20:20
Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (1)
.github/scripts/build_publish_payload.py (1)

165-171: 💤 Low value

Consider filtering trigger types by worker namespace for consistency with functions.

The function processing (lines 151-163) explicitly filters functions by worker_function_ids from the worker object. However, trigger types are collected without verifying they belong to the current worker—the code relies on the deployment-time assumption that only the target worker is connected.

If multiple workers are ever connected during collection (e.g., in a different CI scenario), this could include trigger types from unrelated workers. Consider filtering by namespace prefix (e.g., {worker_namespace}::) similar to how functions are matched, or document the assumption explicitly.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/scripts/build_publish_payload.py around lines 165 - 171, The trigger
collection currently appends every registry trigger type without ensuring it
belongs to the current worker; update the loop that iterates
_extract_array(trigger_types_json, "trigger_types") to only consider trigger
types whose id (tt_id = trigger_type.get("id")) is a string and begins with the
current worker namespace prefix (e.g., f"{worker_namespace}::"), skipping others
(in the same way functions are filtered by worker_function_ids), then call
_normalize_registry_trigger_type and append; reference the variables and
functions triggers, trigger_types_json, _extract_array, tt_id, and
_normalize_registry_trigger_type to locate the change.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In @.github/scripts/build_publish_payload.py:
- Around line 165-171: The trigger collection currently appends every registry
trigger type without ensuring it belongs to the current worker; update the loop
that iterates _extract_array(trigger_types_json, "trigger_types") to only
consider trigger types whose id (tt_id = trigger_type.get("id")) is a string and
begins with the current worker namespace prefix (e.g., f"{worker_namespace}::"),
skipping others (in the same way functions are filtered by worker_function_ids),
then call _normalize_registry_trigger_type and append; reference the variables
and functions triggers, trigger_types_json, _extract_array, tt_id, and
_normalize_registry_trigger_type to locate the change.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 8cadd5b2-9a9b-454f-8eef-b3c3761299e4

📥 Commits

Reviewing files that changed from the base of the PR and between 5694c96 and 1a6945c.

📒 Files selected for processing (2)
  • .github/scripts/build_publish_payload.py
  • .github/scripts/collect_worker_interface.py

@guibeira guibeira merged commit 5bc8f34 into main May 4, 2026
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant