Skip to content

Conversation

@premtsd-code
Copy link
Contributor

@premtsd-code premtsd-code commented Feb 9, 2026

Summary

  • Add messaging resource migration: providers (all 11 types), topics, subscribers, and messages
  • Import non-scheduled messages directly via database for data preservation

Changes

  • Destinations/Appwrite.php — Add importMessagingResource, createProvider (all 11 types), createMessage, createScheduledMessage, resolveTargetId, resolveMessageTargets
  • Sources/Appwrite.php — Add exportGroupMessaging, exportProviders, exportTopics, exportSubscribers, exportMessages, buildTargetUserMap, reportMessaging
  • Resources/Messaging/Message.php — New resource class with targetUserMap for target ID resolution
  • Source.php — Add abstract exportGroupMessaging method
  • Sources/{CSV,Firebase,JSON,NHost}.php — Add empty exportGroupMessaging stubs

Summary by CodeRabbit

  • New Features

    • Full messaging migration support: providers, topics, subscribers and messages can be exported, imported, scheduled and tracked.
    • Messaging is a first-class resource group with batching, reporting counts, target mapping, and message scheduling/status transitions (scheduled, draft, processing).
  • Tests

    • Migration test mocks and export flows updated to include messaging resource types.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Feb 9, 2026

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

  • @coderabbitai resume to resume automatic reviews.
  • @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

  • ▶️ Resume reviews
  • 🔍 Trigger review

Walkthrough

Adds messaging support across the migration system by introducing four new resource types (provider, topic, subscriber, message) and corresponding Resource classes and exporters. Transfer gains a GROUP_MESSAGING and resource lists. Source interfaces add exportGroupMessaging; Appwrite implements listing, reporting, exporting, and importing for messaging (provider creation, topic/subscriber/message handling, scheduling, and target resolution). Local and Mock adapters declare messaging support; CSV/JSON/Firebase/NHost stubs throw Not Implemented. Tests and mocks updated to include messaging resource types.

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~60 minutes

🚥 Pre-merge checks | ✅ 2 | ❌ 1
❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 56.47% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (2 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title 'feat: messaging migration' clearly and concisely summarizes the main change: adding messaging resource migration support. It is specific, directly related to the changeset, and follows conventional commit formatting.

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

✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch feat-message-migration

No actionable comments were generated in the recent review. 🎉


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.

Copy link
Contributor

@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.

Actionable comments posted: 5

🤖 Fix all issues with AI agents
In `@src/Migration/Destinations/Appwrite.php`:
- Around line 1867-1884: The resolveTargetId(Subscriber $resource) currently
returns the source-side target ID when no matching providerType is found, which
is invalid on the destination; change resolveTargetId to signal a failure
instead of returning the stale ID (e.g., throw a descriptive exception like
InvalidArgumentException or return null/a named sentinel) and then update the
caller (createSubscriber) to detect this signal and handle it (skip creation,
log/collect the error, or recreate the target on destination) so an invalid
target ID is never passed to createSubscriber.
- Around line 1557-1590: The switch in importMessagingResource lacks a default
branch so unknown resource names fall through and get marked STATUS_SUCCESS; add
a default case that handles unexpected Resource::getName() values by logging the
unexpected type (use whatever logger is available in this class) and setting
$resource->setStatus(Resource::STATUS_FAILED) (or throw an
InvalidArgumentException) before returning the resource, ensuring
importMessagingResource properly reports failures for unrecognized
Resource::TYPE_* values.
- Around line 1838-1865: resolveMessageTargets currently calls
$this->users->listTargets($userId) and will throw an AppwriteException if the
user is missing, aborting the whole message migration; wrap the listTargets call
inside a try/catch that catches AppwriteException (or a generic exception), skip
adding any targets for that user when an exception occurs, optionally log the
userId and exception, and continue processing other targets; apply the same
pattern to resolveTargetId where $this->users->... is called so individual
resolution failures are skipped instead of failing the entire resource.
- Around line 1767-1831: In createScheduledMessage, the messaging->createPush
call passes null for the $contentAvailable, $critical and $priority parameters
which must be type-appropriate for Appwrite SDK v19; update the createPush
invocation in createScheduledMessage to pass false for $contentAvailable, false
for $critical, and MessagePriority::NORMAL() for $priority (use the SDK enum
reference) instead of null so the call matches the SDK's expected defaults.

In `@src/Migration/Sources/Appwrite.php`:
- Around line 1960-1975: buildTargetUserMap currently calls
$this->users->listTargets($user->getId()) once and only processes the first
page; change it to paginate through all pages for each user by repeatedly
calling Users::listTargets (same method) with the appropriate pagination params
(e.g. limit + offset or cursor/next token depending on the SDK) and appending
each page's $response['targets'] entries into $map[$target['$id']] =
$user->getId() until no further pages remain; ensure the pagination loop is
inside buildTargetUserMap so every user's full target list is resolved.
🧹 Nitpick comments (1)
src/Migration/Sources/Firebase.php (1)

811-815: Nit: Inconsistent exception message casing.

This stub uses 'Not implemented' (lowercase 'i') while the other source stubs (CSV, NHost, JSON) and exportGroupFunctions above use 'Not Implemented' (uppercase 'I').

Suggested fix
     protected function exportGroupMessaging(int $batchSize, array $resources): void
     {
-        throw new \Exception('Not implemented');
+        throw new \Exception('Not Implemented');
     }

Copy link
Contributor

@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.

Actionable comments posted: 1

🤖 Fix all issues with AI agents
In `@src/Migration/Destinations/Appwrite.php`:
- Around line 1723-1743: The createMessage method currently constructs DateTime
directly from Message::getScheduledAt and can throw on malformed input; wrap the
DateTime parsing/comparison in a try/catch inside createMessage (around the new
\DateTime($scheduledAt) > new \DateTime() check) so that any exception when
parsing $scheduledAt is caught and treated as a missing/invalid scheduled time
(set $status = 'draft' and continue), and then call
createScheduledMessage($resource, $resolvedTargets) only when parsing succeeds
and the scheduled time is in the future.

Copy link
Contributor

@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.

Actionable comments posted: 1

🤖 Fix all issues with AI agents
In `@src/Migration/Destinations/Appwrite.php`:
- Around line 1784-1798: In the Appwrite migration code (class Appwrite) adjust
the arguments passed to the SDK methods to match their typed signatures: for
createEmail replace any nulls for $cc, $bcc, and $attachments with empty arrays
([]) and ensure $html is a boolean (use false if no HTML), and for createPush
pass an empty array instead of null for the $data parameter; update the call
sites in the match branch where createEmail and createPush are invoked (use
$data['cc'] ?? [], $data['bcc'] ?? [], $data['attachments'] ?? [],
(bool)($data['html'] ?? false), and $data['data'] ?? []) so all parameters
conform to array/bool types expected by the Appwrite SDK.

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