* Set `maxParallelForks = 1` for most tests, except for screenshot ones
It turns out the Robolectric setup penalty compounds the more parallel JVMs you spawn. Using 1 JVM vs 8 was up to 2.5x faster in local tests.
* Split the roborazzi tests tasks config and CI step
Point to the enterprise submodule rebased on main, which brings the X.509
feature, and resolves the MdmData conflict between the new UseX509 entry and
the split of AccountProvider into AccountProviderServerName,
AccountProviderManagedBaseUrl and AccountProviderManagedCanUseServerName.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Both created a dedicated timeline for each operation performed in a thread, and
never closed it, leaking SDK resources. Apply the same treatment as PollRepository:
replace getTimeline() with a scoped withTimeline() helper, which closes the created
timeline once the operation completes, whether it succeeds, fails or gets cancelled.
In DefaultMediaSender.sendGallery(), waiting for the upload handler is now done
inside the block, so that the timeline stays open until the upload completes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The problem seemed to be sometimes the background work to switch from live timeline to a focused event timeline wasn't finished in time and an assertion failed from time to time.
By providing the coroutine to run this on we can pass a `TestScope` and force it to reliably run immediately instead in unit tests.
PollRepository created a dedicated timeline for each operation performed in a
thread, and never closed it, leaking SDK resources. Replace getTimelineProvider()
with a scoped withTimeline() helper, so that the created timeline is closed once
the operation completes, whether it succeeds, fails or gets cancelled.
The live timeline is left untouched, since it is owned by its room.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The script was relying on the external git-flow tool and on a local
`git config gitflow.*` initialisation, which made its behaviour depend on
the machine setup and hid what was actually done to the branches.
The release branch is now created with `git checkout -b`, and the release
is finished with explicit merge, tag, back-merge and branch deletion
commands. The merge and tag messages are provided explicitly so that the
generated history stays identical to the previous releases. Each step now
aborts the script with a clear message when it fails, instead of letting
the script continue.
Note that tools/release/release.sh (V1) still uses git flow.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Synapse deletes sliding sync connections that have been unused for 7 days. When
an OEM battery manager has kept the application frozen for longer than that, the
next sliding sync request is answered 400 M_UNKNOWN_POS.
The Rust SDK handles that: it resets `pos` and, in offline mode, restarts the
sync. When that recovery gives up, the sync service ends up in the Error or
Terminated state and stops for good, and it is then up to the application to
call start() again. Element X iOS does it, we do not: SyncOrchestrator only
restarts the sync service when its state is Idle, so the sync stays dead for the
rest of the process lifetime.
Nothing recovers from there. The sync never reaches Running, so
waitForE2eeInitializationTasks() never returns, the session verified status
stays Unknown, and the FTUE is stuck on WaitingForInitialState. Clearing the
application data is the only workaround.
Restart the sync service when it is in the Error or Terminated state, with an
exponential backoff from 1s to 30s to avoid hammering a failing homeserver. The
backoff is only reset once the sync service has been running for a while, since
startSync() moves the state to Running right away.
Fixes#7689
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
emptyNode() renders nothing at all, which is fine for a placeholder that is left
within a few frames, but makes the application look frozen when the wait can
last, or never end.
Add a delayBeforeShowingContent parameter to emptyNode(): when it is finite, a
progress indicator and a "Loading…" label fade in after that delay, reusing the
existing DelayedVisibility helper. It defaults to Duration.INFINITE, so the
splash screen keeps rendering an empty canvas.
Use a one second delay on the two placeholders which are not guaranteed to be
left: the FTUE one, rendered while waiting for the session verified status, and
the LoggedInFlowNode one, rendered while the FTUE state is unknown.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Try improving renovate issues with Maven Central rate limiting
Try not to make too many concurrent requests to Maven Central
The logs display rate limit responses followed by OK responses, which could mean we're hammering the Maven Central repo with too many concurrent requests
* Try not hitting Maven Central for `androidx` packages
renovate[bot]
Benoit Marty
ganfra
Jorge Martin Espinosa
ElementBot
bmarty
bxdxnn
Benoit Marty
ganfra