This adds `5.23.0.22-beta` to our list of ignored tags, to avoid this error when running the script:
RuntimeError: 💥 Found unmerged tags: ['5.23.0.22-beta']
We saw this error when deploying 5.25.
"<contact name> can’t be automatically added to this group by you.."
(single person variant) would never be displayed in favor of
"These users can’t be automatically added to this group by you..."
(multiple persons variant).
Pre-keys are refreshed at regular (throttled) intervals, but the
"refresh" operation will only actually upload new pre-keys if the
server says we're running low. In addition, after the "refresh",
there's a "rotation" operation for the signed pre-key if the current
one is more than two days old. This only runs if the refresh was
skipped, since uploading new one-time pre-keys is already an
opportunity to rotate the signed pre-key (and it's worth doing so,
since pre-keys running low can indicate high traffic).
None of this has changed. However, we can now do this for both ACI and
PNI pre-keys. This reworked +[TSPreKeyManager
checkPreKeysWithShouldThrottle:] quite a bit to declare the proper
operation dependencies, which isn't *strictly* necessary because the
queue they're executed on is already limited to a
maxConcurrentOperationCount of 1. We could remove that at this point
with proper use of "barrier" operations, but since all the operations
are hitting the server and account updates have to be serialized on
*that* end, there doesn't seem to be much of a benefit.
After a certain number of failures over a certain number of days, the
app will refuse to send messages until a new signed pre-key can be
uploaded. This should apply to both ACI and PNI pre-key upload
failures. (If we wanted to distinguish them, we could, but this is
mostly a fallback mechanism. Normal pre-key refreshing will come
soon and will not tie the two together.)
...from TSPreKeyManager. This will make it easier to track failures
for ACI and PNI pre-keys separately, and removes some indirection and
possible weird states.
We extend `UIView` with a new method, `renderAsImage`. It always returns a `UIImage`, but we marked its return type as `UIImage?`.
This removes that optionality and updates all callers.
...if the call was more than five minutes ago. This should help in two
scenarios:
- you've been offline for a while, and you see "missed call" but don't
know when they tried to call
- you hit that NSE bug where a ring gets processed hours or even days
later, possibly when a second call arrives
genstrings warns on non-constant strings being passed to
NSLocalizedString, but that happens precisely when we define
OWSLocalizedString. Skip the two files where we define it (one for
each language).
While here:
- Use find's -exec feature rather than a separate xargs invocation.
- Make the script shellcheck-clean.
At launch time, if a primary device doesn't have a PNI identity key,
it should generate one immediately, as well as pre-keys. If a linked
device doesn't have a PNI identity key, it messages the primary to ask
for one; when it gets a response it generates its own pre-keys.
...so it can use an existing one when there is one, which in practice
there always is because we never refresh one-time pre-keys without
rotating our signed pre-key too.
According to [GitHub's docs][0], the `github.base_ref` property "is only
available when the event that triggers a workflow run is either
`pull_request` or `pull_request_target`.
Because of this, pushes were running the following command...
python3 Scripts/precommit.py --ref origin/
...and getting this error:
fatal: ambiguous argument 'origin/': unknown revision or path not in the working tree.
This has been broken for a long time, but it didn't cause CI to fail until
d7c33eb211.
After some discussion, we decided not to run these on pushes to `master`
or `release/*`.
(See also: [this GitHub issue][1] which asks for clarification.)
[0]: https://docs.github.com/en/actions/learn-github-actions/contexts#github-context
[1]: https://github.com/github/docs/issues/13810
