Wire up missing organization Refit clients and fix ChannelUtilization route parameter (fixes #337)

[rolandbanks]

Fixes #337.

What was wrong

Two separate defects, both reported in #337.

1. Organization Refit clients never assigned. The MerakiClient constructor did not assign these, so they were still null after construction and threw NullReferenceException on first use:

• Organizations.Summary.SwitchPower
• Organizations.Appliance.Uplinks.Usage
• Organizations.Wireless.Devices.Latency
• Organizations.Wireless.Devices.PacketLoss
• Organizations.Wireless.Devices.ChannelUtilization

Summary was initialized with only Top, and there was no initializer block at all for Organizations.Appliance or Organizations.Wireless.

2. IOrganizationsWirelessDevicesChannelUtilization could not be built by Refit. All four of its methods spelled the parameter orgnanizationId while the route templates used {organizationId}, so RestService.For<T>() threw:

ArgumentException: URL /organizations/{organizationId}/wireless/devices/channelUtilization/byDevice
has parameter organizationid, but no method parameter matches

This one had to be fixed for the wiring to work, since wiring it up without the fix would throw at new MerakiClient(...) for every consumer.

What changed

• MerakiClient.cs: added the Appliance, Summary.SwitchPower and Wireless initializer entries, placed in the existing alphabetical order.
• IOrganizationsWirelessDevicesChannelUtilization.cs: parameter renamed to organizationId on all four methods, with the matching <param> doc tags.
• MerakiClientSectionWiringTests.cs: new. Needs no network and no API key, because the wiring happens entirely in the constructor.
• CHANGELOG.md: entry under 1.70.42. The version heading is a guess and may need correcting at release.

A second commit fixes 9 pre-existing IDE0058 violations in the test project. .editorconfig sets csharp_style_unused_value_expression_statement_preference = discard_variable, and these statements discarded their value implicitly. Style only, no behaviour change. Happy to drop that commit if you would rather keep it separate.

Verification

• dotnet build Meraki.Api.slnx -c Release: 0 warnings, 0 errors.
• dotnet build Meraki.Api.Test -p:EnforceCodeStyleInBuild=true: 0 warnings, 0 errors (was 9 IDE0058 errors).
• MerakiClientSectionWiringTests and MerakiClientQueryTests: 14 tests, all pass.
• The exact repro from MerakiClient constructor omits organization Refit clients used by Dashboard API; IOrganizationsWirelessDevicesChannelUtilization fails Refit build #337 now prints False for all five properties.
• A reflection walk of the whole section tree confirms wired leaves went from 279 to 284 with no other change, so nothing else was affected.

The wider test suite was deliberately not run, since it exercises and mutates a live Meraki organization.

Scope note

This PR closes the five cases named in #337 and nothing more. A reflection census of the section tree found that 82 further Refit clients and 4 sub-section objects are still left null by the constructor, from the same root cause: the constructor is a hand-maintained initializer mirroring a 134-class section tree, with no test asserting it is complete.

That is raised separately as #357, which also flags two more interfaces carrying the identical orgnanizationId typo (IOrganizationsVpnSiteToSiteIpsec and ICameraCustomAnalyticsArtifacts). They are harmless today only because nothing wires them up, and they will start throwing for everyone the moment the wiring gap is closed.

🤖 Generated with Claude Code

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 8 complexity

Metric	Results
Complexity	8

View in Codacy

AI Reviewer: run a review on demand. To trigger the first review automatically, go to your organization or repository integration settings. AI can make mistakes. Always validate suggestions.

_{TIP This summary will be updated as you push new changes.}