land what's easy to land to reduce stack

land what's easy to land to reduce stack

land what's easily landable to reduce size of stack

fix (possible) minimal encoding of rawCurrentUser if not already minimally encoded.... just spent last 1.5 hours trying to figure out what was wrong, definitely going to add some invariants that would've broke "loudly" instead of erroneously encoding silently

Apologize for additional churn, but looks like changing that flag from Base64.DEFAULT to Base64.NO_WRAP does the trick.

Thanks for taking time to address feedback, looks a lot cleaner!

Didn't do any original research or fact checking, so take it with a grain of salt, but it looks like inclusion of \n character might have to do with some original Base64 MIME spec:

It seems weird to me that the base64 ever ends with newline. Don't have much context into how everything works on native side, but are we always getting it back directly from the android.util.Base64 function? Are we maybe writing it to a file and reading it back at any point?

In D10294#298044, @ashoat wrote:

How come legacyRawThreadInfoValidator isn't removed here? Is it still needed somewhere?

fix

In D10210#297921, @ashoat wrote:

thought happy to create Linear tasks if that'd be prefered.

Yes please!

In D10198#296251, @ashoat wrote:

Yeah, we'll need to think through migrations carefully. We'll also need to migrate all of the data in SQLite from the old format to the new, right?

rebase and land noop refactors

Marking this as [DO NOT LAND] because this would break existing clients at this point.

Realizing my explanation above is probably difficult to follow.

In D10235#297751, @ashoat wrote:

I'd like to try my hand at parameterizing getRelativeMemberInfos. What's the best way to do it? Won't I need at least one usage of the minimally-encoded variant to be able to test that the types work out? Should I check out a later diff?

newline after @flow AND fix TUnion import

Can we update the Props type to handle the "secondary button without primary button" scenario you described using the approach I mentioned in previous comment? That'll also allow us to make buttonContainer more concise and readable.

There should be no case where we render just a secondary button in the button section for modals so I made this change with the intention that if a dev passed in a secondary button w/o a primary button on accident then we would just render the default emptyButtonContainerOffset.

Current status:

temp fix

fix

rebase and land

Guessing you meant something like flow instead of yarn for test plan?

Code changes seem fine, but agree there is some weirdness visually