Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Get-MgGroupMember seems to ignore the -PageSize argument

オープン
  • 何か問題がありますか？
#3,325 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
powershell
領域
api

調査の方向性

まず、-All と異なる -PageSize 値を指定した Get-MgGroupMember の 2 つの Measure-Command ケースを再現します。Get-MgGroupMember のページングのエントリポイントを追跡し、使用されているリクエストまたはページサイズを比較します。完了条件は、コマンドが要求されたページサイズに従うこと、またはその問題が Graph API の動作として説明され、該当する場合は回帰テストが追加されていることです。

索引モデルが issue の本文から書いたものです。

説明

area:documentation Request: Documentation Service issue type:bug
Describe the bug

When calling this function with -PageSize 999, it's pretty obvious that it is ignoring that and still using the default of 100. In my test case, I'm getting the membership of a group that contains about 3000 people. This should take 3 API calls, but instead takes 30. This is my inference based on the lag/delay of the response taking 30 seconds, vs. a few seconds.

Expected behavior

Respect the -PageSize argument, perform better than 10 seconds for a single command

How to reproduce
$group = Get-MgGroup -Filter "DisplayName eq 'group_name'"

Write-Output "Measuring with page size 999"
Measure-Command {
    $members = Get-MgGroupMember -GroupId $group.id -All -PageSize 999
}

Write-Output "Measuring with page size 100"
Measure-Command {
    $members = Get-MgGroupMember -GroupId $group.id -All
}

Write-Output "Member count: $($members.Count)"

As you can see, the duration of this API call is nearly the same, regardless of page size.

Measuring with page size 999
Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 27
Milliseconds      : 721
Ticks             : 277210859
TotalDays         : 0.00032084590162037
TotalHours        : 0.00770030163888889
TotalMinutes      : 0.462018098333333
TotalSeconds      : 27.7210859
TotalMilliseconds : 27721.0859

Measuring with page size 100
Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 31
Milliseconds      : 812
Ticks             : 318127965
TotalDays         : 0.000368203663194444
TotalHours        : 0.00883688791666667
TotalMinutes      : 0.530213275
TotalSeconds      : 31.8127965
TotalMilliseconds : 31812.7965

Member count: 2945
SDK Version

2.17.0

Latest version known to work for scenario above?

No response

Known Workarounds

No response

Debug output
Click to expand log 

The logging output is all sensitive since I'm fetching lists of users, and too large for this input
Configuration

MacOS 15.4.1, though able to reproduce the lag with same module version on Windows 11.

Name                           Value
----                           -----
PSVersion                      7.5.1
PSEdition                      Core
GitCommitId                    7.5.1
OS                             Darwin 24.4.0 Darwin Kernel Version 24.4.0: Fri Apr 11 18:33:39 PDT 2025; root:xnu-114…
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0
Other information

I am unable to determine if this sluggishness is due to the module ignoring -PageSize or due to the Graph API just being too slow for this type of command. Like maybe -PageSize 999 still requires the server to internally fetch in chunks of 100, synchronously, then chunks those responses back to me in the chunks of 999?

主要言語
C#
スター
902
フォーク
233
平均マージ
1日 22時間
マージ済み PR（30日）
29

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

microsoftgraph/msgraph-sdk-powershell のほかの issue

microsoftgraph/msgraph-sdk-powershell の issue をすべて見る

似ている issue

C# の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。