Update SDK to f12d727 (3.0.0-8084-6ad7094) - #2989
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2989 +/- ##
==========================================
+ Coverage 79.53% 79.81% +0.28%
==========================================
Files 1169 1168 -1
Lines 75095 75359 +264
==========================================
+ Hits 59724 60151 +427
+ Misses 15371 15208 -163 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
Claude finished @bw-ghapp[bot]'s task in 7m 54s —— View job SDK bump evaluated
Note the branch head has advanced past this PR's description: the body enumerates the range ending at Compile-time breaksNone found. Both schemes build clean at the current head (
Runtime considerationsNothing here is broken; these are behavior and payload changes worth knowing about.
Everything else in range — confirmed safe
CommitNo commit — nothing needed fixing. The build that verifies this is the baseline run at the current head: both schemes passed ( |
The SDK now populates `MasterPasswordUnlockData.containedKeyId` from the user key, and its own request-model conversion forwards it. iOS builds `MasterPasswordUnlockDataRequestModel` by hand, so it was dropping the field and sending no key ID for users whose key has one — the case bitwarden/sdk-internal#1391 set out to fix.
The SDK bump replaced Client.init(tokenProvider:settings:) with Client.init(tokenProvider:settings:managedSettings:) in bitwarden/sdk-internal#1403 and bitwarden/sdk-internal#1404, which introduced the managed settings crates and their bindings. iOS does not consume the SDK's managed settings channel yet; MDM configuration is read directly from the com.apple.configuration.managed user defaults domain in EnvironmentService. A default ManagedSettingsBindingClient carries no management profile, so behavior is unchanged. Wiring up updateProfile is out of scope for an SDK bump.
The SDK bump mirrored the new `containedKeyId` field from `BitwardenSdk.MasterPasswordUnlockData` onto the request model without a default, so the synthesized memberwise initializer required the argument at every construction site. Meanwhile `main` gained #3019, which adds call sites that construct this model with only `(kdf:masterKeyWrappedUserKey:salt:)`. Each change is fine alone, but the merge commit fails to build. Add an explicit initializer with `containedKeyId: String? = nil`, matching the SDK's own defaulted parameter, while keeping every property `let`. Callers without a key ID compile unchanged and `init(unlockData:)` keeps forwarding the real value. Encoding is unaffected: the synthesized `encode(to:)` uses `encodeIfPresent` for optionals, so a nil `containedKeyId` is still omitted from the JSON body rather than emitted as null.
Updates the SDK from
b7e7be7e7f5adde3cafcb27d79fac80a53c5c3c8tof12d7275e36a567ceda09a70ea941271e3d9985bWhat's Changed
UserCryptoManagementClient.within_v2_migration_grace_periodmethod sdk-internal#1419Raw changelog