Autoreply Laravel Package

Getting Started

1. Install the release: composer require thirtybittech/autoreply and confirm the installed version resolves to 1.2.x.
2. Open the package README first, then inspect the service provider, config file, migrations, and any Conditions directory added for conditional auto-reply logic.
3. Publish and review package assets using the tags documented by the package, then run migrations and clear cached config:

   php artisan vendor:publish --tag=autoreply-config
   php artisan vendor:publish --tag=autoreply-migrations
   php artisan migrate
   php artisan config:clear
   

4. Configure the default transport/channel and enable auto-reply in the published config.
5. First use case: create a rule that only auto-replies when a message matches explicit conditions, e.g. external sender, first contact, matching subject/keyword, and within business hours. Keep an unconditional fallback rule only if you intentionally want broad replies.

The 1.2.0 release adds conditional auto-reply logic. Treat it as an additive feature: start with one narrow rule, verify it in a staging mailbox/queue, then expand conditions.

Implementation Patterns

• Rule-driven replies: Model each auto-reply as a rule with a reply template plus a set of conditions. Evaluate conditions before dispatching the reply, and store enough rule metadata to explain why a reply was or was not sent.
• Event/listener integration: Hook into the package’s inbound-message event or call its evaluator from your existing message-ingestion flow. Keep the condition evaluation close to ingestion so you can short-circuit before expensive rendering or queue work.
• Condition composition: Use condition groups where supported. Prefer small, composable predicates such as sender domain, subject contains, message age, prior reply count, time window, and channel. Avoid one large custom condition class that mixes unrelated business rules.
• Queue replies after commit: Dispatch reply jobs with afterCommit() when rules depend on freshly written records, especially idempotency keys or “already replied” markers.
• Idempotency by design: Add a unique constraint or cache lock keyed by message ID/thread ID and rule ID. Conditional logic increases the chance of duplicate evaluation from retries, webhooks, or multiple queue workers.
• Test both branches: Use Laravel’s event/queue fakes and package test helpers if available. Assert that a matching message dispatches exactly one reply job, and a non-matching message dispatches none.
• Custom conditions: If the package exposes a condition contract, implement small classes and register them in config or the service provider. Keep custom conditions deterministic and unit-test them independently.
• Migration pattern: Leave existing unconditional rules untouched initially. Add conditional rules alongside them, compare behavior in logs, then retire broad rules once conditional coverage is proven.

Gotchas and Tips

• Release metadata is slightly inconsistent: the notes label 1.2.0 while the changelog compares 1.1.1...1.2.1. Verify the actual installed version and review the source diff before relying on exact behavior.
• Check default condition behavior: confirm whether a rule with no conditions still replies unconditionally or now evaluates as “never match.” This is the most likely upgrade surprise.
• Matching semantics matter: test case sensitivity, whitespace, empty strings, null values, HTML vs plain text bodies, and timezone handling for time-window conditions.
• Prevent reply loops: never auto-reply to auto-generated messages, system notifications, no-reply senders, same-domain robot addresses, or messages already carrying auto-reply headers. Add explicit guards even if the package provides some.
• Queue and retry safety: conditional rules may be evaluated more than once by retries or overlapping workers. Use locks/unique keys and make reply jobs idempotent.
• Config cache: after upgrading, re-publish or diff the config and run php artisan config:clear. New condition-related config keys will not appear automatically in older published configs.
• Debugging: log the rule ID, condition results, and final decision. In staging, disable the queue or use Queue::fake() so you can inspect decisions without sending real replies.
• Extension points to inspect: condition contracts/classes, rule evaluation events, reply-sending events, template rendering, and transport/channel drivers. These are the safest places to customize without forking the package.
• Operational guardrails: add rate limits per sender/domain and a global kill switch in config so a misconfigured condition cannot cause a reply storm.