-
Notifications
You must be signed in to change notification settings - Fork 1
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
feat(get-domain-from-backend) Use new Helium API to fetch backend domain #WPB-11287 #27
Conversation
* Update Helium to 1.4.1 * Add assertions to major tests * Remove Consts.java from tests
* Update Helium to 1.4.1 * Add assertions to major tests * Remove Consts.java from tests * Add call to get api version and default domain
final byte[] assetData = client.downloadAsset(msg.getAssetId(), msg.getAssetToken(), msg.getSha256(), msg.getOtrKey()); | ||
final byte[] assetData = client.downloadAsset( | ||
msg.getAssetId(), | ||
null, // TODO(WPB-11287): Change null to default domain |
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.
It shouldn't be the default domain, it should be the domain of the message you got (well, the domain fo the sender). Someome might have send an image from another domain.
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, the comment might be a bit misleading to what it needs to be done, but at least we have an overview of where it will need to be changed as well when we do the database migrations from UUID to QualifiedID (id, domain)
try { | ||
// todo get exception |
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.
What does "todo get exception" means?
TODO: handle exceptions on the GET /api-version
request?
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.
Indeed we forgot, but it is actually the handling of HttpException
for retrieving notifications as now we are using the API call from Helium and not doing the implementation ourselves in LegalHold.
Added the correct catch
NotificationList notificationList = retrieveNotifications(device); | ||
NotificationList notificationList = api.retrieveNotifications( | ||
device.clientId, | ||
device.last, |
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 is interesting, is device.last
the last known notification for the device (client)?
IF so, what was this doing before, downloading ALL notifications every time?
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.
It is the last known notification for the device.
Before it was still using the last known notification, but the handling was being done in a private implementation in LegalHold (so we only passed the device object info), now we call retrieveNotifications from Helium, so explicitly passing all the necessary params e not only the object.
You can check the private implementation from lines 146 to 170 that were deleted in this file in order to use the api call in Helium
private static final ConcurrentHashMap<UUID, File> assets = new ConcurrentHashMap<>();//<messageId, File> | ||
private static final ConcurrentHashMap<UUID, User> users = new ConcurrentHashMap<>();//<userId, User> | ||
private static final ConcurrentHashMap<UUID, File> profiles = new ConcurrentHashMap<>();//<userId, Picture> | ||
private static String DEFAULT_DOMAIN = null; |
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 don't have enough context, but it seems to me that this is an in-memory cache? Or is it persisted?
If it's in-memory only, perhaps the default domain value should be persisted instead, and perhaps the app should throw a fatal error if it has previously stored data (users, conversations, ...) with one domain, but at start up checks the domain with the backend and it's now aa different domain.
Otherwise the code might make a lot of wrong assumptions when looking at old local data. If the data (users, conversations, ...) was stored with null
domain when the default domain was A, but now the defalt domain is B, the data will be inconsistent.
Or do we always store the domain explicitly in the data that is persisted?
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, it is only stored in-memory.
You are correct in the case of the application being shutdown and then changing the domain, when starting again it will assume a different domain and will have inconsistent data (domain) between values that was previously stored.
If that is an issue, then we can persist the default domain in the database and throw a fatal error if when restarting the service and the fetched domain from /api-version
is different from the one persisted, then we can throw a fatal error.
Should we have a quick meeting between me, you and @spoonman01 about the final approach? or can we continue with what was said:
- If in DB default domain is null, fetch from
/api-version
and persist it. - if in DB default domain is NOT null, when fetching from
/api-version
and the values are different, we throw a fatal exception.
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.
To be honest, this situation (the domain changes) is extremely unlikely, but I like to do a bit of defensive programming. So we should look at this with a risk-cost analysis. Is the change to consider this scenrio a substantial change that will take a while to implement? Then perhaps we accept the risk. Is it relatively easy to implement? Then I would implement it.
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.
We created a new table called Metadata
that holds 2 fields :key
and value
(so it can also be used later if we need more metadata/configs to be saved)
And also created a file called FallbackDomainFetcher
where it runs on service start to verify if it contains a value in Cache, otherwise fetch from the API and compare against what is saved in the database (if there is any domain saved).
In case the domain received from the API is different from the one in the database, then we are throwing a RuntimeException
.
* Update Helium to 1.4.1 * Add assertions to major tests * Remove Consts.java from tests * Add call to get api version and default domain * Persist fallback domain to database * Add FallbackDomainFetcher to handle fetch from cache, database and API
* Update Helium to 1.4.1 * Add assertions to major tests * Remove Consts.java from tests * Add call to get api version and default domain * Persist fallback domain to database * Add FallbackDomainFetcher to handle fetch from cache, database and API * Properly receive thrown exception from dropwizard task execution * Add Mockito for testing mocks * Add JavaDoc for FallbackDomainFetcher
* Update Helium to 1.4.1 * Add assertions to major tests * Remove Consts.java from tests * Add call to get api version and default domain * Persist fallback domain to database * Add FallbackDomainFetcher to handle fetch from cache, database and API * Properly receive thrown exception from dropwizard task execution * Add Mockito for testing mocks * Add JavaDoc for FallbackDomainFetcher
# Conflicts: # src/main/java/com/wire/bots/hold/Service.java
Quality Gate passedIssues Measures |
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.
Changed the status to approved to remove the blocker, but @spoonman01 will review the code
Can't approve formally because I was the one opening the PR, because of some Git issues last week. |
PR Submission Checklist for internal contributors
The PR Title
SQPIT-764
The PR Description
What's new in this PR?
Issues
Using old version of Helium
Solutions
Update Helium in order to leverage new API and objects
Dependencies (Optional)
Smaller PRs on Helium and Xenon
PR Post Submission Checklist for internal contributors (Optional)
References
feat(conversation-list): Sort conversations by most emojis in the title #SQPIT-764
.