Describe the bug
When creating a channel with membershipType set to ChannelMembershipType.Shared, the graphClient.teams().byTeamId(teamId).channels().post(channel) method returns null instead of a Channel object.
This works correctly for standard and private channel types, which return the expected Channel object.
Root cause analysis
According to the Microsoft Graph API documentation (Example 5 — Create a shared channel), creating a shared channel returns an HTTP 202 Accepted with a Location header pointing to a teamsAsyncOperation, whereas standard/private channels return a 201 Created with the Channel object in the response body.
The SDK's .post() method appears to only handle the 201 Created case, deserializing the response body into a Channel object. When it receives a 202 Accepted (with no Channel in the body), it returns null without providing access to the response headers or the async operation.
This is the same issue reported in the .NET SDK: microsoftgraph/msgraph-sdk-dotnet#1728
Expected behavior
One of the following:
-
Preferred: The SDK should detect the 202 Accepted response, follow the Location header, poll the teamsAsyncOperation until completion, and return the resulting Channel object — providing a consistent developer experience across all channel types.
-
Alternative: The SDK should return a wrapper type (e.g., ChannelPostResponse) that can represent either a Channel (for 201) or a TeamsAsyncOperation (for 202), along with the Location/Content-Location headers.
-
Minimum: The documentation should clearly state that .post() returns null for shared channels, and provide a documented pattern to retrieve the channel using NativeResponseHandler (or equivalent in Java).
How to reproduce
ChannelMembershipType type = ChannelMembershipType.Shared;
Channel channel = new Channel();
channel.setOdataType("#Microsoft.Graph.channel");
channel.setMembershipType(type);
channel.setDisplayName("My Shared Channel");
channel.setDescription("Test shared channel creation");
LinkedList<ConversationMember> members = new LinkedList<>();
AadUserConversationMember conversationMember = new AadUserConversationMember();
conversationMember.setRoles(List.of("owner"));
HashMap<String, Object> additionalData = new HashMap<>();
additionalData.put("user@odata.bind",
"https://graph.microsoft.com/v1.0/users('" + ownerId + "')");
conversationMember.setAdditionalData(additionalData);
members.add(conversationMember);
channel.setMembers(members);
// This returns null for shared channels, but works for standard/private
Channel result = graphClient.teams().byTeamId(teamId).channels().post(channel);
System.out.println(result); // null
SDK Version
6.62.0
Latest version known to work for scenario above?
6.62.0
Known Workarounds
None
Debug output
Click to expand log
```
</details>
### Configuration
_No response_
### Other information
_No response_
Describe the bug
When creating a channel with membershipType set to ChannelMembershipType.Shared, the graphClient.teams().byTeamId(teamId).channels().post(channel) method returns null instead of a Channel object.
This works correctly for standard and private channel types, which return the expected Channel object.
Root cause analysis
According to the Microsoft Graph API documentation (Example 5 — Create a shared channel), creating a shared channel returns an HTTP 202 Accepted with a Location header pointing to a teamsAsyncOperation, whereas standard/private channels return a 201 Created with the Channel object in the response body.
The SDK's .post() method appears to only handle the 201 Created case, deserializing the response body into a Channel object. When it receives a 202 Accepted (with no Channel in the body), it returns null without providing access to the response headers or the async operation.
This is the same issue reported in the .NET SDK: microsoftgraph/msgraph-sdk-dotnet#1728
Expected behavior
One of the following:
Preferred: The SDK should detect the 202 Accepted response, follow the Location header, poll the teamsAsyncOperation until completion, and return the resulting Channel object — providing a consistent developer experience across all channel types.
Alternative: The SDK should return a wrapper type (e.g., ChannelPostResponse) that can represent either a Channel (for 201) or a TeamsAsyncOperation (for 202), along with the Location/Content-Location headers.
Minimum: The documentation should clearly state that .post() returns null for shared channels, and provide a documented pattern to retrieve the channel using NativeResponseHandler (or equivalent in Java).
How to reproduce
SDK Version
6.62.0
Latest version known to work for scenario above?
6.62.0
Known Workarounds
None
Debug output
Click to expand log ```