feat: webhook and schedule triggers

[a7m-1st]

Description

Trigger System Core Implementation

• WebhookTrigger: Complete HTTP webhook server implementation with aiohttp backend

  • Configurable port, path, and host binding
  • Support for JSON and form-encoded payloads
  • Comprehensive error handling and logging
  • Integration with TriggerManager for event processing

• TriggerManager: Central orchestration system for all trigger types

  • Supports ChatAgent and Workforce integration patterns
  • Event-to-Task conversion for seamless workflow integration
  • Automatic trigger registration and lifecycle management
  • Database adapter support for persistent trigger state

Slack Integration & Authentication

• SlackAuth: Production-ready webhook signature verification

  • HMAC-SHA256 signature validation following Slack security best practices
  • Timestamp freshness checks to prevent replay attacks
  • URL verification challenge/response handling for Slack App setup
  • Environment variable configuration (SLACK_SIGNING_SECRET, SLACK_BOT_TOKEN)

• Slack Webhook Example: Complete integration demonstration

  • Event type handling (url_verification, event_callback, messages, app_mention)
  • Proper error handling and graceful degradation without credentials
  • Real-world usage patterns with comprehensive logging

TODOs & Next Steps

• Add unit tests for trigger system components with appropriate pytest markers
• Add configuration validation and better error messages
• Implement trigger scheduling and rate limiting features
• Implement specific DatabaseTrigger adapters (PostgreSQL)
• Implement trigger state persistence and recovery mechanisms

Technical Notes

• All components follow CAMEL's type annotation requirements
• Proper logger usage instead of print statements throughout
• Environment variable configuration for secure credential management
• Comprehensive error handling with meaningful context messages

Checklist

Go over all the following points, and put an x in all the boxes that apply.

• I have read the CONTRIBUTION guide (required)
• I have linked this PR to an issue using the Development section on the right sidebar or by adding Fixes #issue-number in the PR description (required)
• I have checked if any dependencies need to be added or updated in pyproject.toml and uv lock
• I have updated the tests accordingly (required for a bug fix or a new feature)
• I have updated the documentation if needed:
• I have added examples if this is a new feature

If you are unsure about any of these, don't hesitate to ask. We are here to help!

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[LuoPengcheng12138]

All looks good to me!

[a7m-1st]

Hi there @LuoPengcheng12138 I have added some small updates:

1. According to your comment, simplified the payload passing (passing the whole payload now)
2. Added a new allow_duplicate_events param bcz turns out I receive duplicate events sometimes

[a7m-1st]

@Wendong-Fan @nitpicker55555 @LuoPengcheng12138
I have added docs, test cases and general enhancements. I think should be good to go !

[fengju0213]

thanks for awesome pr @a7m-1st ！ left some comments

[fengju0213]

I think the current default routing (Workforce/ChatAgent branches) is OK as a
convenience, but it’s also a bit “baked in.” A cleaner design might be to expose a
unified handler abstraction so users decide what happens after a trigger, and the
default Workforce/ChatAgent handlers become just optional implementations.

Something like:

  class TriggerEventHandler(Protocol):
      async def handle(self, event: TriggerEvent) -> Any: ...

TriggerManager just calls handler.handle(...)

This keeps the trigger pipeline extensible, avoids hard‑coding two paths, and makes it
easier for users to plug in their own logic. It would be great to document an example
handler interface in the docs as well.

[a7m-1st]

Thanks for the suggestion, yes you are right. Although it would be one more step of configuration to the developer, but it would lift some burden from the trigger manager.

I have just updated it to have ChatAgent, Workforce, Callback and Workforce handlers. Those are made for heavy-duty where all triggers under the manager share a single instance. A user can also opt for per trigger callbacks via trigger.add_callback(my_function). In its simplest form:

from camel.triggers.handlers import ChatAgentHandler
from camel.agents import ChatAgent

agent = ChatAgent(system_message="You are a helpful assistant.")
handler = ChatAgentHandler(
    chat_agent=agent, #Optional, uses open-ai by default
    default_prompt="Process this trigger event: {event_payload}"
)

manager = TriggerManager(handler=handler)
await manager.register_trigger(trigger, auto_activate=True)

[fengju0213]

calling a sync method inside an async handler may stall the event loop.

[a7m-1st]

All right using astep I hope that is okay?
I will refactor it with the TriggerEventHandler as well

[a7m-1st]

Thanks @lightaime and @fengju0213 for your review 🙌 , I will make sure to tend to them asap.