Resiliency to newly-added capabilities #32
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ebuggerDisplay to represent unknown capabilities in the returned string. Made a copy of the Allowed class called AllowedRaw.cs in Bytewizer.Backblaze.Client.Internal that represents capabilities as a list of plain strings, with method ParseCapabilities to transform instances into the original Allowed class. Updated LangVersion in Backblaze.Client.csproj to 8.0 to allow the use of the coalescing assignment operator. Made a copy of AuthorizedAccountResponse.cs in Bytewizer.Backblaze.Client.Internal that uses AllowedRaw instead of Allowed. Updated AuthorizeAccountAsync to use AuthorizeAccountResponseRaw for the actual request and then convert the result to the regular AuthorizedAccountResponse structure, with ParseCapabilities splitting off unknown capabilities.
|
@logiclrd Thanks again for your contribution. I will take a look that these pull requests this weekend. You don't by any chance have any test cases for these additions? |
|
I tested them by hand, by temporarily undoing the previous PR that added the new capabilities for bucket notifications. I'll have to look into whether there's a simple way to test this from the other side... |
- Added an AssemblyInfo class to Backblaze.Client.csproj with an InternalsVisibleTo attribute allowing Backblaze.Tests.Unit access to internal members. - Added references from Backblaze.Tests.Unit.csproj to NSubstitute, Bogus, FluentAssertions and ASP.NET Core (in order to use Kestrel). - Added class TestServer.cs to Backblaze.Tests.Unit to create an in-process hosted web server for testing purposes. - Added text fixture class ApiClientFixture.cs to Backblaze.Tests.Unit with tests of the AuthorizeAccountAync method, including specifically Capabilities Resiliency. Moved the initialization of Allowed.Capabilities and Allowed.UnknownCapabilities out of the loop in AllowedRaw.ParseCapabilities and added explicit initialization for Capabilities.
…o use explicit strings instead of Faker-generated strings for unknown capability names, since there is a tiny change of faker.Random.Words(3) returning the same string twice.
|
@microcompiler There you go. :-) |
…e for the Backblaze.Tests.Unit project.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backblaze periodically adds new "capabilities" to the B2 API. The current strategy for parsing the models associated with successful logins requires all capabilities to be recognized. This breaks the library every time it happens. This PR aims to provide resiliency to this situation, by making the raw parsing of the "Allowed" structure in new type
AllowedRawjust use a list of strings for the capabilities, and then later sorting them into known and unknown capabilities for the actualAllowedobject returned by theConnectcall.