Skip to content
Snippets Groups Projects
  1. Dec 10, 2024
  2. Dec 09, 2024
  3. Dec 05, 2024
  4. Dec 04, 2024
  5. Dec 03, 2024
  6. Dec 02, 2024
  7. Nov 29, 2024
  8. Nov 28, 2024
    • Richard van der Hoff's avatar
      Fix new scheduled tasks jumping the queue (#17962) · d80cd57c
      Richard van der Hoff authored
      Currently, when a new scheduled task is added and its scheduled time has
      already passed, we set it to ACTIVE. This is problematic, because it
      means it will jump the queue ahead of all other SCHEDULED tasks;
      furthermore, if the Synapse process gets restarted, it will jump ahead
      of any ACTIVE tasks which have been started but are taking a while to
      run.
      
      Instead, we leave it set to SCHEDULED, but kick off a call to
      `_launch_scheduled_tasks`, which will decide if we actually have
      capacity to start a new task, and start the newly-added task if so.
      d80cd57c
  9. Nov 27, 2024
  10. Nov 26, 2024
  11. Nov 25, 2024
    • Erik Johnston's avatar
      Fix up logic for delaying sending read receipts over federation. (#17933) · 3943d2fd
      Erik Johnston authored
      For context of why we delay read receipts, see
      https://github.com/matrix-org/synapse/issues/4730.
      
      Element Web often sends read receipts in quick succession, if it reloads
      the timeline it'll send one for the last message in the old timeline and
      again for the last message in the new timeline. This caused remote users
      to see a read receipt for older messages come through quickly, but then
      the second read receipt taking a while to arrive for the most recent
      message.
      
      There are two things going on in this PR:
      1. There was a mismatch between seconds and milliseconds, and so we
      ended up delaying for far longer than intended.
      2. Changing the logic to reuse the `DestinationWakeupQueue` (used for
      presence)
      
      The changes in logic are:
      - Treat the first receipt and subsequent receipts in a room in the same
      way
      - Whitelist certain classes of receipts to never delay being sent, i.e.
      receipts in small rooms, receipts for events that were sent within the
      last 60s, and sending receipts to the event sender's server.
      - The maximum delay a receipt can have before being sent to a server is
      30s, and we'll send out receipts to remotes at least at 50Hz (by
      default)
      
      The upshot is that this should make receipts feel more snappy over
      federation.
      
      This new logic should send roughly between 10%–20% of transactions
      immediately on matrix.org.
      3943d2fd
    • dependabot[bot]'s avatar
      93cc9550
  12. Nov 22, 2024
Loading