Skip to content

Promote v1.19.3 to production - #3583

Merged
mrubens merged 4 commits into
mainfrom
release/v1.19.3
Oct 24, 2026
Merged

mrubens merged 4 commits into
mainfrom
release/v1.19.3

Conversation

@mrubens

@mrubens mrubens commented Oct 24, 2026

Copy link
Copy Markdown
Contributor

Promote v1.19.3

Frozen at e12f170159444cca3217a687887e6940d9a16b96 — the commit where 1.19.3 was versioned. Commits merged to develop afterward require an explicit candidate refresh or ship in the next release.

  • Merge this PR with a merge commit (do not squash or rebase).
  • If multiple promote PRs are open, merge them in version order (oldest first).
  • Monitor CI and reviews on this PR's current head, not only the release-preparation PR. Unresolved findings and missing required approvals remain blockers even with green CI.
  • After a refresh or CI reconciliation, re-check the new head; monitoring never authorizes merging or publication.
  • Merging publishes a GitHub Release for v1.19.3 and triggers the existing GHCR v* image publish (latest channel).
  • The release/v1.19.3 branch can be deleted after this PR merges.

Changelog

1.19.3 (2026-10-24)

Roomote 1.19.3 keeps scheduled automations and worker health checks running reliably while memory history backfills make progress in the background.

Highlights

  • Keep memory history backfills from crowding out scheduled automations and worker health checks.
  • Automatically repair outdated scheduler offsets so heartbeat and automation checks return to their intended cadence.

Patch changes

  • Memory history backfills no longer pile up overlapping collector runs that delay scheduled automations, make worker health checks go stale, and trigger repeated worker restarts. Collection runs one at a time and yields between bounded backfill passes, preserving progress for the next scheduled run.
  • Scheduled heartbeat and automation checks now recover their intended cadence after an interval change instead of continuing to run late because of an outdated scheduler offset. Roomote repairs affected schedules automatically when the background worker starts.

roomote-roomote Bot and others added 4 commits October 23, 2026 14:56
Co-authored-by: Roomote <roomote@roomote.dev>
…rval (#3580)

* [Fix] Re-create bullmq job schedulers whose offset outgrew their interval

bullmq keeps an every-scheduler's stored offset when its interval changes and
adds the whole offset when catching up on missed iterations, so a scheduler
that once ran hourly and now runs every minute keeps firing about hourly. The
heartbeat then goes stale between runs (failing /health/bullmq) and per-minute
work such as custom automation checks runs late.

On startup, remove any scheduler whose offset is not smaller than its interval
before the upserts re-create it with a fresh offset.

* fix: collect stale schedulers before removing them

Schedulers are paged by sorted-set rank, so removing them while paging shifted
later entries left and skipped stale ones past the first page.

---------

Co-authored-by: Matt Rubens <2600+mrubens@users.noreply.github.com>
…er (#3581)

* [Fix] Stop overlapping brain collector runs from starving the scheduler

BrainCollectors runs on the shared scheduler worker every 15 minutes, and its
historical backfill loop kept going as long as passes made progress. A long
backfill (for example a large Notion workspace) left each run looping while
the scheduler started a new one every tick, until every worker slot held a
collector run. The heartbeat and per-minute jobs then never ran, the liveness
watchdog exited the process, and stalled collector runs restarted on boot,
repeating until the platform stopped restarting the service.

- Only one BrainCollectors run collects at a time; a tick that finds one in
  flight finishes immediately.
- A run stops looping after a 10-minute budget, well under the 15-minute
  cadence; the next tick resumes the backfill.

* fix: resume PR facts from their exact cursor after a budget-ended run

A collector run that ended on its time budget mid-backfill made the next run
rewind PR facts by the overlap window. When one pass filled the budget, every
tick rewrote the same facts and never advanced. Remember (in-process) that the
last run ended on its budget and resume PR facts from the exact saved cursor;
the overlap rewind still applies when a scan starts fresh or after a restart.

---------

Co-authored-by: Matt Rubens <2600+mrubens@users.noreply.github.com>
Co-authored-by: @mrubens <2600+mrubens@users.noreply.github.com>
@roomote-community

roomote-community Bot commented Oct 24, 2026 •

Copy link
Copy Markdown
Contributor

1 issue outstanding. See session

Reviewed e12f170

};
},
});
resumePullRequestFactsExactly = outcome === 'budget';

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[P2] Restore PR overlap when the PR scan itself has caught up

outcome describes all collectors, so a long Notion/Slack backfill sets resumePullRequestFactsExactly even when syncPullRequestFacts returned progressed: false and finished its scan. Subsequent scheduled ticks then keep skipping the PR overlap window for as long as that unrelated backfill exhausts the budget. The analytics writer deliberately shares one timestamp across sequential repository writes, so a later-committed fact behind the saved tuple is missed; if other facts advance the watermark by more than 24 hours before the backfill settles, the eventual overlap cannot recover it. An isolated probe of this orchestration with a settled PR scan and budget-consuming integration backfill produced overlap flags [true, false, false] across three scheduled runs. Preserve exact continuation only while PR facts themselves remain unfinished, and restore scheduled overlap once that source catches up.

@mrubens
mrubens merged commit b532d7e into main Oct 24, 2026
56 of 57 checks passed
@mrubens
mrubens deleted the release/v1.19.3 branch October 24, 2026 02:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant