-
Notifications
You must be signed in to change notification settings - Fork 832
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Port send jslib to mobile #1219
Conversation
a30ce2d
to
e77ca14
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looking great. just a few comments
Took the testing infrastructure from bitwarden/server
These are mostly happy-path tests to ensure a reasonably correct implementation
e77ca14
to
07a2258
Compare
src/Core/Services/SendService.cs
Outdated
response = await _apiService.PostSendFileAsync(fd); | ||
break; | ||
default: | ||
response = new SendResponse(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This default behavior idea might just be a bad one. It's identifying a possible future bug and recovering from it in a hard-to-track-down manner.
I think throwing would be better. Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, please add throw
here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I ended up adding the throw only here.
I don't think we want to throw whenever we encounter one since that would do bad things like lock up Sync if clients get out of date relative to servers.
Instead, we should just keep the client from ruining saved data by complaining last minute that it doesn't know what it's doing.
I think it's best to only throw on unknown send types here. I don't think we want to throw whenever we encounter one since that would do bad things like lock up Sync if clients get out of date relative to servers. Instead, keep the client from ruining saved data by complaining last minute that it doesn't know what it's doing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, please hold merge until after the release [code-freeze]
Overview
Port of Send PRs to jslib (bitwarden/jslib#190, bitwarden/jslib#192, bitwarden/jslib#205, bitwarden/jslib#242). This PR does not implement any actual use of the SendService.
Testing
Projects
Common
This project is a copy from the bitwarden/server/Core.Test project, with some additions. Given the similarity here, we should think about creating a new repo for common testing items and accessing them through a submodule.
Core.Test
This is a test bed for the Send feature I'm implementing. Crypto tests are copied from jslib tests. Send model and service tests are happy path tests to ensure proper function since I'm not implementing anything that uses them.
Automated Testing
An Automated test runner is added to the
android
job. Unfortunately,dotnet
is not capable of building theandroid
andiOS
projects, so it is run against only theCore.Test
project. We'll have to add another line per test project we add.Files Changes/Added
Core.Test
project to the android job pipeline.test/Common.csproj
andtest/Core.Test
Testing Files Changes
Common
Core.Test