In retrospect I should hold off on landing this until D7453 is shipped to clients first. It only affects user registration and we can assume they will be using newer client versions, but we should still wait until it actually ships before landing this, in order to avoid blocking keyserver deploy
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Apr 17 2023
Add code comment
- Update to use updateThread utility so that updates are correctly created for all clients
- Only reset thread names to the empty string if they are for SIWE users. For other users it won't affect behavior on new clients, but will break old clients
Talked with this offline with @ginsu and we concluded that EditAvatar is being overloaded and doing two things instead of one. We concluded we're going to split this component and EmojiAvatarCreation into two components
Thanks for explaining @marcin! To your queue for folly::Optional<std::string>
Just added Ginsu to Dropbox
Not sure familiar with this stuff – would be great if @atul could take a look
Please address inline comments before landing!
Apr 16 2023
Apr 15 2023
I should either:
Having identity service be aware of the "websocket payload", also couples identity service to being aware of the websocket implementation. Which would mean that the client messages would need to reside in a shared location (not necessarily a bad thing, but it is an implication of making the messages opaque).
Sorry yeah I didn't actually check!! Looks like it's just the unit test failure
Apr 14 2023
Bye bye
It's cool how the ThreadAvatar / ChildAvatar is a child of EditAvatar
Our messages got crossed when you re-requested review I think, passing back to you for my more recent message where I discuss tradeoffs
My proposal: single TunnelbrokerService with a single RPC that takes targetDeviceID and generic message (API will probably expand in the future though)
Can you explain a little bit more these two decisions:
Apr 13 2023
@atul is rather busy right now and probably won't be able to review anytime soon, but if I recall correctly I think he was the original architect of the message ops, so would be good for him to take a pass here
Didn't review too closely since it looks like just a "factor out" diff. Please wait for CI to pass before landing
Does nothing actually use this component? Usually we'd have to update some import paths as well
S3 now defaults to virtual bucket addressing, which is not supported by localstack
In D7382#220558, @rohan wrote:In D7382#220270, @ashoat wrote:Also ESLint errors are concerning, we should get those resolved
Will do - ran yarn eslint:fix web/ for each of the diffs in this stack, so the ESLint errors should be resolved in the updates (I'll double check this once I put up the revisions)
Still seeing ESLint issues. Might be good to make sure you're able to confirm locally that all ESLint issues are resolved before updating the diff again
Apr 12 2023
The issues with threads started from images was more complicated than I realized.
I would have included this in D7402. It's hard to understand the need for this function (vs. the existing hash function approach) without reading your comment here. In general I think small utility functions like this should be introduced alongside their callsite, to make it easier for the reviewer to understand why / how they're being introduced. A good rule of thumb (not a hard rule) is whether you have unit tests for it.
New dependency looks good!! 1.2k stars on GitHub, updated in the last month, and MIT-licensed
Also ESLint errors are concerning, we should get those resolved
It's hard to know how to review this diff when we don't know how the types will be used. Is it possible to combine this diff with another one that uses the types?
On the prod it might be a lot slower - should we display a spinner or something? How would the UI look if messages are being fetched?