Skip to content

fix(ci): drop engine built-in trigger types from publish via baseline diff#77

Merged
guibeira merged 1 commit intomainfrom
fix/trigger-types-diff-baseline
May 5, 2026
Merged

fix(ci): drop engine built-in trigger types from publish via baseline diff#77
guibeira merged 1 commit intomainfrom
fix/trigger-types-diff-baseline

Conversation

@guibeira
Copy link
Copy Markdown
Collaborator

@guibeira guibeira commented May 5, 2026

Summary

Every worker we've published recently has a log trigger type that it doesn't register itself (exampleimage-resize/v0.1.8). iii-hq/iii's observability module (engine/src/workers/observability/mod.rs:1487-1494) registers log as a built-in trigger type with no engine:: prefix:

let log_trigger_type = TriggerType::new(
    LOG_TRIGGER_TYPE,           // = "log"  (mod.rs:226)
    "Log event trigger",
    Box::new(self.clone()),
    None,
);
let _ = self.engine.register_trigger_type(log_trigger_type).await;

Both filters miss it: the engine's include_internal: false only skips engine::* (engine_fn/mod.rs:587), and so does our normalizer (post-#73). log ends up attached to every worker.

Fix

Take a baseline snapshot of engine::trigger-types::list after the engine is ready but before the target worker starts. Diff against the post-worker list — what the target added is what we publish.

Start III engine                            ← engine + built-in trigger types live (e.g. `log`)
NEW: Snapshot trigger types baseline        ← write trigger-types-baseline.json
Start local worker (cargo / release-binary) ← target worker registers its own types
Collect worker interface                    ← exclude any id present in the baseline

Why this approach

Scenario Hardcode {log} Engine renames to engine::log Diff snapshot
Engine adds another flat built-in leaks only if also renamed filtered
Engine renames logengine::log dead code filtered filtered
Coordinated change with iii-hq/iii? no yes no

Self-correcting: any new engine built-in is automatically excluded next publish without changes here.

Implementation

  • New workflow step Snapshot engine trigger types baseline between engine ready check and Start local worker for interface collection. One iii trigger call (~100ms) writing trigger-types-baseline.json.
  • collect_worker_interface.py gains --trigger-types-baseline <path> and reads the file if it exists.
  • normalize_worker_interface accepts baseline_trigger_types_json and skips any id already present.

Test plan

  • After merge, dispatch create-tag.yml for image-resize (no own trigger types) — published triggers is [].
  • Dispatch for skillstriggers contains skills::on-change and prompts::on-change only (no log).
  • Confirm Snapshot engine trigger types baseline step prints a JSON containing at least {"id": "log"} so the filter has something to match.

… diff

Every worker has been publishing a `log` trigger type that it doesn't actually register. iii-hq/iii's observability module (engine/src/workers/observability/mod.rs:1487-1494) registers `log` as a built-in trigger type without an `engine::` prefix, so neither the engine's own `include_internal: false` filter (engine_fn/mod.rs:587) nor our post-#73 namespace filter catches it; the type leaks into every worker's payload.

Snapshot `engine::trigger-types::list` between `Start III engine` and `Start local worker for interface collection`, then have `normalize_worker_interface` exclude any id present in that baseline. The diff is exactly what the target worker added — robust to future built-ins the engine may register without an `engine::` prefix, with no hardcoded names.

The collect script accepts `--trigger-types-baseline <path>` and treats a missing file as no baseline, so the script still works standalone for ad-hoc runs.
@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented May 5, 2026

Warning

Rate limit exceeded

@guibeira has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 6 seconds before requesting another review.

To keep reviews running without waiting, you can enable usage-based add-on for your organization. This allows additional reviews beyond the hourly cap. Account admins can enable it under billing.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 62e4559d-7ac2-4dbd-b1b6-d566e36ed93e

📥 Commits

Reviewing files that changed from the base of the PR and between f528fd0 and 184c130.

📒 Files selected for processing (3)
  • .github/scripts/build_publish_payload.py
  • .github/scripts/collect_worker_interface.py
  • .github/workflows/_publish-registry.yml
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch fix/trigger-types-diff-baseline

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

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

@guibeira guibeira marked this pull request as ready for review May 5, 2026 12:14
@guibeira guibeira merged commit 957e96c into main May 5, 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