If a user's database is corrupted, we now try to fix it. I recommend
reviewing `DatabaseRecovery` to see how this works, and
`DatabaseRecoveryViewController` for the bulk of the UI.
_This change should have no user impact._
This cleans up the way we generate registration IDs. It:
- Rewrites the generation code in Swift
- Removes the "sneaky transaction" method. I did this for clarity, and
because we won't use it for much longer
- Turns a log warning into a regular log—generating a registration ID is
not a problem
- Adds tests
I think this is a useful change on its own, but will be handy for an
upcoming change, too.
Once initialized, a URLSession’s configuration can’t be changed. In
order to transfer the headers, assign them to the configuration before
assigning the configuration to the session.
* Split OWSSignalService into a swift protocol and implementation, migrated from objc
* Put OWSSignalService under SSKEnvironment and use mock in mock environment
* Rename from basename + impl to protocol + basename
* extend mock functionality a bit
* pr feedback
The non-lazy map and filter always make a new array or dictionary,
which is often consumed immediately into a Set. Using `lazy` avoids
that intermediate allocation, as well as the need to loop over the
array or dictionary a second time.
This is a micro-optimization, but several of these accessors are
accessed fairly frequently, so we might as well make them faster.
To improve message reliability, we're adding an urgency flag to outgoing
messages. For example, outgoing calls are urgent, but delivery receipts
are not. [Android][] and [Desktop][] have already done this work.
At a high level, I added an `isUrgent` property to `TSOutgoingMessage`s.
It defaults to `true`. Some subclasses, like
`OWSReceiptsForSenderMessage`, override it to return `false`.
Builds off of a few other commits (not necessary to understand this
commit, but might be useful for posterity):
- e858a0d916
- 8c6d2ebe8c
- 402b117221
- 2ba0cd764d
- 266a4663e9
- 8e5009bbf7
[Android]: dc04c8ed98
[Desktop]: 06190b1434
This change should have no user impact because it only changes
comments.
We had some comments that referenced the Signal server repo. They
referenced a commit that was a little out of date (from March 2022).
This updates the links.
This removes `FeatureFlags.giftBadgeReceiving` and
`FeatureFlags.giftBadgeSending`, replacing them with
`RemoteConfig.canReceiveGiftBadges` and
`RemoteConfig.canSendGiftBadges`.
If DNS resolution fails, then it’s expected that there won’t be any
addresses. Fail gracefully in this case.
If DNS resolution succeeds and provides a non-nil but empty list of
addresses, report an error. This shouldn’t happen.
Some users [are unable to register][1] because the server [returns a 400
error][2] if passed an invalid `Accept-Language` header.
This commit helps prevent two possible error modes:
- Filters out invalid language tags. Some users reported a "Workshopx"
language, which the server would reject because it's syntactically
invalid. Deleting this language (at the OS level) let them register.
- If no languages are valid, we should send `*` instead of the empty
string. There's no evidence that this happened in practice.
In addition, this commit:
- Adds tests.
- Sends a maximum of 10 languages instead of 6.
- Omits the `q` value when it's 1 because [that's the default][3].
- Marginally improves performance by iterating lazily.
[1]: https://github.com/signalapp/Signal-iOS/issues/5261
[2]: bf6d3aa324/service/src/main/java/org/whispersystems/textsecuregcm/controllers/AccountController.java (L271-L275)
[3]: https://www.rfc-editor.org/rfc/rfc9110.html#section-12.4.2
Co-authored-by: Nora Trapp <nora@signal.org>
Previously, sending a gift badge was not a durable operation, which
meant that crashes/failures could cause users to have their payment
methods charged without actually sending the badge.
Now, the flow is split up into two steps: non-durable parts before the
charge is attempted, and durable parts afterward.
The high-level flow is:
1. Prepare the payment, which involves a couple of repeatable network
requests.
2. Enqueue a job with the prepared payment, that:
1. Charges the payment method (idempotently)
2. Requests a receipt credential (idempotently)
3. Enqueues a gift message, and optionally a text message
3. When the job completes, open the conversation in the UI.
If you've got the `giftBadgeSending` flag enabled, you can now send gift
badges to anyone who has the capability.
This commit doesn't complete the feature, though. It is missing:
- Proper durability and error handling (to be addressed separately)
- Saving of receipts
- A few other cleanups
This makes a few small changes to `OWSRequestFactory.boostCreatePaymentIntent()`:
- Adds tests
- Rewrites the function in Swift
I made sure I could do a boost (in staging) in the simulator.
* Little fix for context menu
* Add 'My Stories' section to stories tab
* Add new story thread types
* Show stories in conversation picker
* Support for sending stories
* Update story list when sending stories
* Add basic 'My Stories' view controller
* Initial stories settings screens
* Consolidate TSPrivateStoryThread and TSMyStoryThread into one class
* Require an explicit read transaction to initialize an outgoing message
* Fix linting
* Allow enabling group story from internal settings
* Fix tests
* PR Feedback
This respects the `giftBadges` capability when trying to send gift
badges. In other words, it prevents you from sending gift badges to
someone who lacks the capability.
The bulk of this change involves fetching and saving of this new
capability. The rest of the code involves showing it on the "choose
recipient" screen (and some debug screens).
The gist is:
```diff
-foo = foo + 1
+foo += 1
```
Most of the violations were in generated files, so I changed and re-ran the generator.
A few of these violations required implementing some new methods, which I added tests for.
See [the docs for this rule][0].
[0]: https://realm.github.io/SwiftLint/shorthand_operator.html
We sometimes attempt to do N operations at once where up to N of them
end up getting caught by the rate limiter. This should *not* turn into
N push challenges, or else we'll get rate limited for that too.
In at least one instance (iOS 14.6), we've seen pings go out that
never get responses and never report timeouts. Check for that
explicitly to make sure we cycle the socket if we're not getting ping
responses.
The normal reachability manager would never get configured during
testing because it waited for AppReadiness. However, it still created
an OWSURLSession, and if between tests the previous reachability
manager wasn't destroyed fast enough, trying to set up a new one would
create a second URL session with the same background identifier, which
isn't allowed.
Fix this by providing a MockSSKReachabilityManager, which is never
reachable by default, and while here update the background identifier
to be something descriptive.
This adds the first screen for badge gifting. It lets you see the gift
badge, pick the currency, and advance to the next screen.
It also adds a skeleton for the next screen, so there's somewhere to
advance to, but that screen is unfinished.
All of this is behind disabled flags, so this should have no user
impact.
* Ignore `exclusiveProcessIdentifier` parameter
This was added in fee1bbddad, but the `NS_UNAVAILABLE` declarations
weren’t updated, which led to warnings in Xcode.
* Ignore `TSThread` initializer in subclasses
* Fix `TSAttachmentPointer` ignored initializer
* Add missing initializers to `TSMessage` subclasses
This only handles the immediate subclasses. There’s still more warnings
in the extended hierarchy, but those don’t seem to have been handled as
consistently in the first place, so updating them is more involved.
This only calls the block, and the formatting in the old design made it
particularly difficult to read. (It also makes this path and the success
path more similar in their construction.)
