Skip to content

fix(migrations): report membership counts - #13598

Open
HarshMN2345 wants to merge 2 commits into
mainfrom
fix/migration-report-membership
Open

fix(migrations): report membership counts#13598
HarshMN2345 wants to merge 2 commits into
mainfrom
fix/migration-report-membership

Conversation

@HarshMN2345

Copy link
Copy Markdown
Member

What

MigrationReport had no rule for memberships, so the count the Appwrite source already computes was dropped on the way out.

The source counts memberships per team while building a report (reportAuth walks each team and adds listMemberships(...)->total), but with no addRule for it the value never reaches the response. A report came back showing teams with nothing behind them, and a caller sizing up a migration had no way to see how many memberships it would move.

Observed against a real 1.9.6 source — the response carried user, team, provider, topic, subscriber and message, and no membership key at all despite it being requested:

{"user":3,"team":2,"provider":1,"topic":2,"subscriber":2,"message":2,...}

Changes

  • MigrationReport.php — one addRule for Resource::TYPE_MEMBERSHIP, next to the team rule it belongs with.
  • tests/unit/Utopia/Response/Model/MigrationReportTest.php — new, following ExecutionTest.

Testing

  • vendor/bin/phpunit tests/unit/Utopia/Response/Model/MigrationReportTest.php — passes, and fails without the rule
  • composer lint — passed on both files
  • phpstan --level 4 on both files — no errors

Note

This adds a field to a response model, so the API specs want regenerating before release. The Generate Specs workflow is workflow_dispatch-only and publishes to appwrite/specs, so I have left it alone rather than running it from a PR branch.

The Appwrite source counts memberships per team while building a report,
but the response model had no rule for them, so the count was computed
and then dropped on the way out. A report therefore showed teams with
nothing behind them, and a caller sizing up a migration had no way to see
how many memberships it would move.
@greptile-apps

greptile-apps Bot commented Sep 10, 2026

Copy link
Copy Markdown
Contributor

RetriggerConfidence Score: 5/5

The PR appears safe to merge; the previously implementation-coupled test has been replaced with behavioral serialization coverage.

Summary

  • Adds the membership count to MigrationReport as an integer defaulting to zero.
  • Verifies that explicit membership totals survive response serialization.
  • Verifies that reports without membership data serialize the field as zero.

Reviews (2) · Last reviewed commit: "test(migrations): assert the serialized ..."

Comment thread tests/unit/Utopia/Response/Model/MigrationReportTest.php
@github-actions

github-actions Bot commented Sep 10, 2026

Copy link
Copy Markdown

✨ Benchmark results

Comparing main (before) → fix/migration-report-membership (after).

Metric Before After Change
🚀 Requests/sec 231.32 218.47 🔴 -5.6%
⏱️ Latency P50 75.06 ms 80.5 ms 🔴 +7.2%
⏱️ Latency P95 176.98 ms 185.72 ms +4.9%
Per-scenario breakdown & investigation details

Metrics below reflect the current branch (after). Δ P95 compares against the base.

Scenario P50 (ms) P95 (ms) Requests RPS Δ P95 (ms)
API total 80.5 185.72 13,680 218.47 +8.74
Account 152.26 270.28 720 12.18 -5.32
TablesDB 77.17 140.91 7,440 120.95 +11.75
Storage 75.09 158.36 3,600 60.38 +11.47
Functions 121.17 231.67 1,920 32.96 +15.58

Top API waits (after)

API request Max wait (ms)
account.name.update 480.83
functions.delete 415.84
functions.variables.delete 396.36
functions.variables.create 369.31
functions.create 361.53

Checking the model's rules only proved the key was configured; it would
have stayed green if the count were dropped or reshaped on the way out.
Serialize a report instead and read the count back off the payload.
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